[swift-evolution] [Pitch] New Version of Array Proposal

[Félix Cloutier]

> Le 24 juil. 2017 à 10:43, Tino Heth <2th at gmx.de> a écrit :
> 
> 
>> The last point is especially worrying to me because things like non-type generic parameters are *much bigger* than fixed-size arrays.
> 
> Why do you think that's the case?

This is a bit of a naive thing to say since we don't have non-type generic parameters, but it seems to me that there's essentially no contention that if we had it, we'd only need a shorthand (N x T) syntax to create a tuple of N objects of type T to implement a FixedSizeArray<T, N> struct in the standard library. It would already respond to the biggest needs: it can be layout-compatible with arrays in C structs, the tuple syntax migration is manageable (if we even want it), implementing Sequence on it is easy, it has well-understood copy semantics, the type declaration is unambiguous.

By contrast, the "non-type generic parameters" point hides that, at the very least, the ABI needs to change to support this and the generic syntax will need a makeover to support both type and non-type parameters. In addition, they will almost certainly motivate a debate on what "constant expression" means in Swift and the possibilities of compile-time evaluation. They open up other type possibilities that will probably need to be discussed, like `Foo<N>: Foo<N-1>`. And of course, that doesn't even mention that Swift still hasn't realized its "baseline vision" <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md> of generics.

It's also a matter of impact. Fixed-size arrays are useful, to me included, but they don't really create new opportunities for things that just couldn't be done before. Non-type generic parameters do.

> And even if it's really more challenging than FSAs:
> Would that be enough justification to add a bunch of language changes right now, ignoring more general concepts which offer a good syntax for them without extra cost?

It seems to me that I'm the one advocating for fewer language changes, and the majority of sub-features that are being requested here don't feel particularly more general to me.

In its current form, this proposal tackles a contentious syntax to declare fixed-length arrays and a similarly contentious syntax to initialize them, it has multi-dimensional arrays, unpacking of arrays as parameter lists, zero-size types with alignment requirements, sized array literals, explicit conversions between array types, rules for deterministic initialization, vector types. Out of these, I could see parameter unpacking and vectors used for more than fixed-size arrays. (I haven't been through the entire discussion, though, so you might be able to point out a few more.)

There's also a number of issues that aren't addressed in the document, which I feel are obscured by the sheer number of things that it asks to consider: for instance, as we mentioned on another thread, Swift anonymous types can't conform to protocols, so it's not clear what fixed-size arrays have to be under the hood to be iterable.

Of course, if you take all of that, that's possibly bigger than non-type generic parameters, but I question whether it all needs to pass at the same time, or even if there are things that could be dropped to make this more manageable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170724/e1fb3efb/attachment.html>