<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 24 juil. 2017 à 10:43, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">The last point is especially worrying to me because things like non-type generic parameters are *much bigger* than fixed-size arrays.</span></div></blockquote></div><div class="">Why do you think that's the case?</div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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 <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md" class="">"baseline vision"</a> of generics.</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">And even if it's really more challenging than FSAs:</div><div class="">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?</div></div></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></body></html>