I would defend turning tuples into structs (change from structural type to nominal type). This is a much better story for programmers, compare the two stories:
1. Tuples are just syntax sugar for simple structs. 2. Tuples are sort of like structs but there is a list of things tuples can do that structs can't and a list of things structs can do and tuples can't. I think unification can be achieved with some name mangling (Chris Lattner noted this previously - I am just spelling out one scheme), e.g.: // var a = (zero: 0, one: 1) public struct Tuple_zero_Int_one_Int { // Mangle name. public var zero: Int public var one: Int } var a = Tuple_zero_Int_one_Int(zero: 0, one: 1) // a.0 = -1 a.zero = -1 // var b = (0, 1) public struct Tuple_0_Int_1_Int { // Mangle name. public var _0_: Int // Unique name. public var _1_: Int // Unique name. } var b = Tuple_0_Int_1_Int(_0_: 0, _1_: 1) // a = b a = Tuple_zero_Int_one_Int(zero: b._0_, one: b._1_) Implicit in the above transformation is: 1. struct and tuple have the same memory layout. 2. `.0` access the 1st stored property of a struct, `.1` the 2nd, etc. -- Howard. On 22 November 2017 at 18:02, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > > > On 22 Nov 2017, at 07:54, Douglas Gregor <dgre...@apple.com> wrote: > > > > On Nov 21, 2017, at 10:48 PM, David Hart <da...@hartbit.com> wrote: > > > > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Nov 21, 2017, at 10:37 PM, Chris Lattner <clatt...@nondot.org> wrote: > > On Nov 21, 2017, at 9:25 PM, Douglas Gregor <dgre...@apple.com> wrote: > > Or alternatively, one could decide to make the generics system *only and > forever* work on nominal types, and make the syntactic sugar just be sugar > for named types like Swift.Tuple, Function, and Optional. Either design > could work. > > > We don’t have a way to make it work for function types, though, because of > parameter-passing conventions. Well, assuming we don’t invent something > that allows: > > Function<Double, inout String> > > to exist in the type system. Tuple labels have a similar problem. > > > I’m totally aware of that and mentioned it upthread. > > > Eh, sorry I missed it. > > There are various encoding tricks that could make this work depending on > how you want to stretch the current generics system… > > > I think it’s straightforward and less ugly to make structural types allow > extensions and protocol conformances. > > > Can somebody explain to me what is less ugly about that? I would have > naturally thought that the language would be simpler as a whole if there > only existed nominal types and all structural types were just sugar over > them. > > > See Thorsten’s response with, e.g., > > Function<Double, InoutParam<String>, Param<Int>> > > which handles “inout” by adding wrappers around the parameter types (which > one would have to cope with in any user of Function), but still doesn’t > handle argument labels. To handle argument labels, we would need something > like strings as generic arguments. We’d also need to handle calling > conventions and anything else we invent for function types. > > > Oh ok, I get. The ugliness comes from trying to shoehorn structural types > into nominal types. > > - Doug > > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution