Here are some questions I keep asking myself and can't find the answer to, maybe someone can help:
It seems to be understood that it's a good thing to reuse the existing repeat keyword, even if some of us think it doesn't explain what it does. Similarly for each, which I didn't even know was a keyword.
Is there a fundamental reason we need to repeat the word each everywhere? Can't we do like with protocol conformance for normal generics, we write <T: Equatable> in the declaration and then just T everywhere else. That would seem much clearer to me, since as far as I understand it, T alone will not be used anywhere under the current proposal, so each doesn't actually add any information except in the <>.
It is emphasized that we can't have two unlabeled variadic arguments in a function, but can we ever have any unlabeled arguments?
It is said that we can't do Shape(U) == Shape(V) but why is that?
I seem to remember there being discussion in another thread about how in the general case this could enable type-level linear algebra, which doesnāt sound like an efficient thing to make the compiler do.
The proposal does have a concept of requiring two pack parameters to have the same shape; it just doesn't have a special spelling for it.
We don't want to allow you to do things like requiring one pack parameter to have the same shape as the concatenation of two other pack parameters, though, because yeah, that does turn into algebraic simplification eventually.
I donāt personally have any need for type-level linear algebra, but Iām curious why we donāt want people to do that. Iām assuming that whatās meant is not anything like that itās go-to-style āharmfulā. Is the fear that the required implementation would negatively impact compiler performance even for users who write no explicit shape requirements?
each also appears before references to pack values in expressions, where it plays more of a role. For example, it allows us to have a conversion from tuples to packs (there will be a pitch about that soon). It also improves type checker performance by removing a scalability problem.
Itād be a lot of work, and there are better things for compiler writers to do. If we find a compelling reason to allow it, we can always revisit it, or revisit it selectively.