Make sequtils.zip return seq of anonymous tuples

[kaushalmodi]

Earlier the tuples had named fields "a" and "b" and that made it
difficult to assign the zip returned seqs to other vars which expected
seqs of tuples with field names other than "a" and "b".

[krux02]

You should add a test that tests the behavior that you want. Test the assignment to a named tuple with some arbitrary names.

[kaushalmodi]

@krux02 That's a good idea. I'll get such a test in by tomorrow.

[krux02]

I just want to mention that I was once bothered by the field names in the tuple as well. So thumbs up for this PR.

[kaushalmodi]

Thanks :) I have updated the tests.

[mratsim]

So anonymous tuples can be assigned to other anonymous tuples or to named tuples (i.e. structural typing) but named tuples can only be assigned to other named tuples (i.e. "string"/"identifier" typing).

I think this part is underspecified. Also while we tuple destructuring works for both anonymous and named tuple, maybe a function or magic that anonymize named tuples is needed for function call chaining like the original case?

[kaushalmodi]

but named tuples can only be assigned to other named tuples (i.e. "string"/"identifier" typing)

No, named tuples can be assigned to named tuples with the exact name fields, or also to any anonymous tuple.

https://scripter.co/notes/nim/#tuple-type-equality

[Varriount]

Does this break backwards compatibility at all?

[kaushalmodi]

@Varriount Yes, slightly, if someone is relying on inferred typing.

E.g. this will break:

let foo = zip(someSeq1, someSeq2)
echo foo.a

But this will not break:

let foo: seq[tuple[a:int, b:int]] = zip(someSeq1, someSeq2) # of course the types of a and b fields are assumed here
echo foo.a

[krux02]

Good point about the breaking behavior. We do have a backwards compatibility claim. But I am still positive for this change, since I really do like it. You should introduce a backwards compatibility branch. This is how you do it:

when (NimMajor, NimMinor) <= (1, 0) # 1.0.x
  # old declaration here
else:
  # new declration here

Of course you also need to have a test for the old version (reintroduce the broken tests into another file that is compiled with --useVersion:1.0. Sorry for this inconvenience.

[kaushalmodi]

OK, I'll get to this later today.

I have a question though..

Does the CI run all the tests with and without --useVersion:1.0.

[Araq]

Does the CI run all the tests with and without --useVersion:1.0.

No and it's worse than that, right now --useVersion:1.0 doesn't do anything (yet!).

[kaushalmodi]

Also, looks like --useVersion:1.0 would apply to the whole core? So if someone wants old version of zip, they would need to take the old versions of everything?

Update: I'm not staying that that is bad. I am just confirming what I understand here. It's good that people get either all the old stuff in one go or all the new better stuff. If they choose to keep their code untouched and frozen in Nim 1.0, then this wouldn't make any difference to them.

[Araq]

Yes, it applies to the whole core.

[kaushalmodi]

@krux02 , @Araq : Please review the new commit added to make zip backwards compatible: c0b597c

---

The only thing is that right now, there isn't a robust way to test out both of those when/else clauses.

[kaushalmodi]

I have redone the code change to make zip backward compatible using the tip from @PMunch (https://play.nim-lang.org/#ix=20MO).

/cc @narimiran @PMunch Can you please review c0b597c ?