[swift-evolution] Subclass Existentials

Adrian Zubarev adrian.zubarev at devandartist.com
Thu Feb 2 01:44:52 CST 2017


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 (swift-evolution at swift.org) schrieb:



Sent from my iPhone

On Feb 1, 2017, at 8:46 PM, Slava Pestov <spestov at apple.com> wrote:


On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:


On Feb 1, 2017, at 3:13 PM, David Hart <david at hartbit.com> wrote:

Second question inline:



Sent from my iPhone
On 1 Feb 2017, at 23:09, David Hart <david at 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 <dgregor at apple.com> wrote:


On Jan 29, 2017, at 8:39 AM, David Hart <david at 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

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 at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170202/ea3f6aa6/attachment.html>


More information about the swift-evolution mailing list