> On 22 Nov 2017, at 07:54, Douglas Gregor <dgre...@apple.com> wrote: > > > >> On Nov 21, 2017, at 10:48 PM, David Hart <da...@hartbit.com >> <mailto:da...@hartbit.com>> wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> >>>> On Nov 21, 2017, at 10:37 PM, Chris Lattner <clatt...@nondot.org >>>> <mailto:clatt...@nondot.org>> wrote: >>>> >>>> On Nov 21, 2017, at 9:25 PM, Douglas Gregor <dgre...@apple.com >>>> <mailto:dgre...@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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
