[swift-evolution] Subclass Existentials

[Douglas Gregor]

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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170201/cfe7ed4d/attachment.html>