> On Jul 23, 2017, at 7:27 PM, Félix Cloutier <[email protected]> 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 <[email protected]> a écrit : >> >> On Jul 22, 2017, at 3:03 PM, Daryle Walker <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
