> Le 24 juil. 2017 à 10:43, Tino Heth <2...@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
