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

David Hart david at hartbit.com
Wed Nov 22 00:48:18 CST 2017



> 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.

> 	- 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/20171122/f7bb7152/attachment.html>


More information about the swift-evolution mailing list