[swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

[Daryle Walker]

> On Jul 23, 2017, at 7:27 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
> 
> I think I've already said that, but I agree that an incremental approach to this would be better.
> 
>> Le 23 juil. 2017 à 15:57, Chris Lattner <clattner at nondot.org> a écrit :
>> 
>> On Jul 22, 2017, at 3:03 PM, Daryle Walker <darylew at mac.com> wrote:
>>>> In my opinion, there is an easy three step plan :-) to solving this problem, riffing on Array:
>>> 
>>> Well, fixed-size arrays don’t have initializers, for the same reason tuples don’t: they’re compound types instead of named types and they literally have nowhere to place initializer definitions. But like tuples, FSAs have a literal syntax that works as a substitute for full-blown initializers.
>> 
>> Ok, sure.  They aren’t literally initializers in the stdlib (they are built into the compiler), but they have initialization semantics and can be spelled in whatever way makes ergonomic sense.  Keeping them aligned with Array seems like a good starting point.
> 
> Either way, in the context of fixed-size arrays, I think that it's a broader problem that anonymous types can't have anything attached to them. This also prevents fixed-size arrays from conforming to protocols, even Sequence, and Swift would need variadic generics or (possibly, depending on the syntax) non-type generic parameters to even create a wrapper.

My solution to tuples and fixed-size arrays not supporting attached interfaces is to make a strong type-alias to the compound type and add your interface there. And unlike alternatives added to the core language level, users who don’t want that particular extended interface (or want an incompatible one!) don’t have to live with it. It’s part of the “alternative types” proposal.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com