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

[Tony Allevato]

Does that mean that once structural types can conform to protocols, would
the core team want to remove Optional as a nominal type and just use “T?”?
Or has that ship sailed because of source compatibility and you just don’t
want to introduce any new nominals that shadow structurals?

On Tue, Nov 21, 2017 at 3:10 PM Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> On Nov 21, 2017, at 3:05 PM, Slava Pestov <spestov at apple.com> wrote:
>
>
>
> On Nov 21, 2017, at 6:02 PM, David Hart <david at hartbit.com> wrote:
>
> Can somebody explain to me what are
>  nominal and structural types and why Optional should really be a
> structural type?
>
>
> Nominal types are structs, enums, protocols and classes. They have
> declarations in source and are uniquely identified by their name.
> Structural types are functions, meta types, protocol compositions, and
> tuples.
>
> The distinction is not as clear as you might think because as Chris said,
> you can imagine tuple being implemented as ‘struct Tuple<T…>’, similarly
> functions and meta types could also be written as such. It is mostly a
> syntactic distinction in the language, but it has far-reaching consequences
> in internal representations, which is why for now it would be tricky to
> have structural types conform to protocols.
>
>
> Right. Optionals are a tricky case because we wanted them to be nominal so
> we could write extensions on them and make them conform to protocols, but,
> they’re so integral to the language that they are really treated like a
> structural type.
>
> - 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/20171121/6ee5346f/attachment.html>