<div dir="ltr">on Date: Tue, 21 Nov 2017 22:54:21 -0800 Douglas Gregor <<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>> wrote:<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> On Nov 21, 2017, at 10:48 PM, David Hart <<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>> wrote:<br>
><br>
> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<br>
><br>
>><br>
>> I think it’s straightforward and less ugly to make structural types allow extensions and protocol conformances.<br>
><br>
> 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.<br>
<br>
See Thorsten’s response with, e.g.,<br>
<br>
Function<Double, InoutParam<String>, Param<Int>><br>
<br>
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.<br>
<br></blockquote><div><br></div><div>can you outline how extensions and protocol conformances might look for structural types? to compare the ugliness of both approaches.</div><div><br></div><div>Mike</div><div><br></div></div></div></div></div>