typealias AnyObject = … is nice to have, but how about if we fully drop the class constraint-keyword and generalize AnyObject instead?
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? The former is similar to the debate we had last year about Any vs. Any<…>, where we decided to go with a magical Any. 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?)? 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. -- Adrian Zubarev Sent with Airmail Am 2. Februar 2017 um 05:52:41, Douglas Gregor via swift-evolution ([email protected]) schrieb: Sent from my iPhone On Feb 1, 2017, at 8:46 PM, Slava Pestov <[email protected]> wrote: On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution <[email protected]> wrote: On Feb 1, 2017, at 3:13 PM, David Hart <[email protected]> wrote: Second question inline: Sent from my iPhone On 1 Feb 2017, at 23:09, David Hart <[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]> wrote: On Jan 29, 2017, at 8:39 AM, David Hart <[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 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] https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
