> On 22 Nov 2017, at 07:54, Douglas Gregor <[email protected]> wrote: > > > >> On Nov 21, 2017, at 10:48 PM, David Hart <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> >>>> On Nov 21, 2017, at 10:37 PM, Chris Lattner <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> On Nov 21, 2017, at 9:25 PM, Douglas Gregor <[email protected] >>>> <mailto:[email protected]>> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
