iproduct: generate tuples for simpler cases too

[Philippe-Cholet]

Fixes #868
Allow trailing commas is convenient when the macro is on multiple lines.

Fixes #869
It is more consistent to return tuples in every case.
It however is a breaking change.
Note the new case: the empty product generating a single unit tuple (), similar to the recent #835.

What do you think?
EDIT: 2nd option, we can fix the first one and close the second.

PS: I note that semver-checks does not see much breaking changes lately.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (1f69c53) 94.20% compared to head (5ab11d6) 94.08%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #870      +/-   ##
==========================================
- Coverage   94.20%   94.08%   -0.12%     
==========================================
  Files          48       48              
  Lines        6676     6676              
==========================================
- Hits         6289     6281       -8     
- Misses        387      395       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[phimuemue]

I think we should do this.

my gut feeling is that the Macro has a bit many branches, but I think we can clean that up later if we want to

[Philippe-Cholet]

I just added some simple tests.

my gut feeling is that the Macro has a bit many branches, but I think we can clean that up later if we want to

It would have even more branches if we ever do #264

(Similarly, for izip, there is #267.)

[jswrenn]

I'm a little hesitant to make this breaking change. I appreciate the argument for consistency, but (T,) is a somewhat exotic type — unary tuples are basically never used in Rust. However, I concede that this might be useful in tandem with code that abstracts over tuple arity, e.g., with frunk or in the invocation of another macro. I also don't think we need to wait for someone to run into this particular edge case, since it's not particularly likely they'll also report it. Given this, I'm okay with approving this PR.

[ijackson]

(T,) is a somewhat exotic type

Indeed. But iproduct!( just_one_iterator ) is weird too. In practice people won't write such code by hand very often. Even when they do (eg when messing about trying to decide between code patterns, or commenting bits out, or something) providing the unary tuple will probably be more convenient as it'll involve less editing of the code that handles the output elements.

Given this, I'm okay with approving this PR.

Thanks.