[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Howard Lovatt]

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 at swift.org> wrote:

>
>
> On 22 Nov 2017, at 07:54, Douglas Gregor <dgregor at apple.com> wrote:
>
>
>
> On Nov 21, 2017, at 10:48 PM, David Hart <david at hartbit.com> wrote:
>
>
>
> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> On Nov 21, 2017, at 10:37 PM, Chris Lattner <clattner at nondot.org> wrote:
>
> On Nov 21, 2017, at 9:25 PM, Douglas Gregor <dgregor at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171123/43896716/attachment.html>