> On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev <adrian.zuba...@devandartist.com >> <mailto:adrian.zuba...@devandartist.com>> wrote: >> >> typealias AnyObject = … is nice to have, but how about if we fully drop the >> class constraint-keyword and generalize AnyObject instead? >> > That’s a good point. My *technical* goal is for AnyObject to cease to be a > protocol, because it’s really describing something more fundamental (“it’s a > class!”). Whether we spell that constraint as “class” or “AnyObject” doesn’t > affect that technical goal. > > I’d gravitated toward the “class” spelling because the idea of a class > constraint seems most naturally described by “class”, and it’s precedented in > C#. > > However, the changes in SE-0095 > <https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md> > to make “Any” a more fundamental type (and not just a typealias) definitely > open the door to doing the same thing with “AnyObject”—just make it a > built-in notion in the language, and the spelling for a class constraint. It > *certainly* works better with existentials. > >> In the future we might want to add AnyValue with value (semantics) >> constraint, would that mean that we’d need another keyword there like value? >> > “value” would be a terrible keyword, as you know. Point taken :) > > If we did something like this, we would probably want it to be akin to > ValueSemantics—not just “it’s a struct or enum”, but “it provides value > semantics”, because not all structs/enums provide value semantics (but > immutable classes do). > >> Speaking of the future directions: >> >> Now that we’re no longer supporting the idea of Any<…> syntax and any type >> prefixed with Any seems to be special for its particular usage, could we >> safely bring the empty Any protocol back (is this somehow ABI related?)? >> > From an implementation standpoint, the choice to make AnyObject a magic > protocol was a *horrible* decision. We have hacks throughout everything—the > compiler, optimizers, runtime, and so on—that specifically check for the > magic AnyObject protocol. So, rather than make Any a magic protocol, we need > to make AnyObject *not* magic. > >> One day after this proposal is accepted, implemented and released, we >> probably will talk about the where clause for existentials. But since a lot >> of the existentials will have the form typealias Abc = …, this talk will >> also include the ability to constrain generic typealiases. >> > By “one day” I suspect you mean “some day” rather than “the day after” :) > > Yes, I feel like this is a natural direction for existentials to go.
Looking ahead to when this is on the table, I'm a little worried about the syntactic implications of constrained existentials now that the Any<> syntax doesn't seem to be as popular. The obvious way to go would be 'X & Y where …' But that leads to ambiguity in function declarations func doTheThing<T>() -> X & Y where … where T == … This could be resolved by requiring constrained existentials to be typealiased to return them, but I don't think there's any other situations where we require a typealias to use something, and it just feels like a workaround. David > > - Doug > > >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 2. Februar 2017 um 05:52:41, Douglas Gregor via swift-evolution >> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: >> >>> >>> >>> Sent from my iPhone >>> >>> On Feb 1, 2017, at 8:46 PM, Slava Pestov <spes...@apple.com >>> <mailto:spes...@apple.com>> wrote: >>> >>>> >>>>> On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>>> >>>>>> On Feb 1, 2017, at 3:13 PM, David Hart <da...@hartbit.com >>>>>> <mailto:da...@hartbit.com>> wrote: >>>>>> >>>>>> Second question inline: >>>>>> >>>>>> >>>>>> >>>>>> Sent from my iPhone >>>>>> On 1 Feb 2017, at 23:09, David Hart <da...@hartbit.com >>>>>> <mailto:da...@hartbit.com>> wrote: >>>>>> >>>>>>> I did consider it, but didn’t want to put too much on your plate for >>>>>>> Swift 4. But if you’re mentioning it, I’ll go ahead and add it to the >>>>>>> second version of the proposal. >>>>>>> >>>>>>> By the way, what you is your point of view about the discussions we’ve >>>>>>> had concerning the positioning of the class constraint? >>>>>>> >>>>>>> David. >>>>>>> >>>>>>>> On 1 Feb 2017, at 22:58, Douglas Gregor <dgre...@apple.com >>>>>>>> <mailto:dgre...@apple.com>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Jan 29, 2017, at 8:39 AM, David Hart <da...@hartbit.com >>>>>>>>> <mailto:da...@hartbit.com>> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> As promised, I wrote the first draft of a proposal to add class >>>>>>>>> requirements to the existential syntax. Please let me know what you >>>>>>>>> think. >>>>>>>>> >>>>>>>>> https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/XXXX-subclass-existentials.md >>>>>>>>> >>>>>>>>> <https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/XXXX-subclass-existentials.md> >>>>>>>> This looks good! I’m looking forward to the second draft, but I have >>>>>>>> one question. >>>>>>>> >>>>>>>> Did you consider the generalized “class” constraint? IIRC, this was in >>>>>>>> Austin’s larger proposal, and it allowed for (e.g.) >>>>>>>> >>>>>>>> typealias CustomStringConvertibleClass = class & >>>>>>>> CustomStringConvertible // class that conforms to >>>>>>>> CustomStringConvertible >>>>>>>> >>>>>>>> and potentially a wonderful cleanup where AnyObject ceases to be a >>>>>>>> weird special protocol and instead becomes >>>>>>>> >>>>>>>> typealias AnyObject = Any & class >>>>>>>> >>>>>> >>>>>> Austin's proposal defines it as: >>>>>> >>>>>> typealias AnyObject = class >>>>>> >>>>>> Is Any necessary? >>>>> >>>>> Nah, it should be okay to just have “class” there. >>>> >>>> This would mean ‘class’ can appear anywhere we expect to parse a type, or >>>> would we have a special grammar rule for the RHS of a typealias? >>> >>> This is sorta why I'm nervous about it and suggested the "Any & class" >>> thing. In theory any type can in an expression, so >>> >>> class.self >>> >>> Would be a valid expression. >>> >>> I don't think it's actually ambiguous, but it feels... odd. And can mess >>> with parser recovery. >>> >>> - Doug >>> >>> >>>> Slava >>>> >>>>> >>>>> - Doug >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution