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

[David Hart]

> 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 <mailto:david at hartbit.com>> wrote:
>> 
>> 
>> 
>> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> 
>>>> On Nov 21, 2017, at 10:37 PM, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
>>>> 
>>>> On Nov 21, 2017, at 9:25 PM, Douglas Gregor <dgregor at apple.com <mailto: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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171122/096812b7/attachment.html>