> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev <[email protected]> > 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. - Doug > > > -- > Adrian Zubarev > Sent with Airmail > > Am 2. Februar 2017 um 05:52:41, Douglas Gregor via swift-evolution > ([email protected] <mailto:[email protected]>) schrieb: > >> >> >> Sent from my iPhone >> >> On Feb 1, 2017, at 8:46 PM, Slava Pestov <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>>> On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> >>>>> On Feb 1, 2017, at 3:13 PM, David Hart <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Second question inline: >>>>> >>>>> >>>>> >>>>> Sent from my iPhone >>>>> On 1 Feb 2017, at 23:09, David Hart <[email protected] >>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> >>>>>>>> On Jan 29, 2017, at 8:39 AM, David Hart <[email protected] >>>>>>>> <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
