[swift-evolution] Subclass Existentials

David Smith david_smith at apple.com
Thu Feb 2 16:54:01 CST 2017 

> On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev <adrian.zubarev at devandartist.com <mailto:adrian.zubarev at 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 at swift.org <mailto:swift-evolution at swift.org>) schrieb:
>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>> On Feb 1, 2017, at 8:46 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>>> 
>>>> 
>>>>> On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Feb 1, 2017, at 3:13 PM, David Hart <david at hartbit.com <mailto: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 <mailto: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 <mailto:dgregor at apple.com>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Jan 29, 2017, at 8:39 AM, David Hart <david at hartbit.com <mailto: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 <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 <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/bee8678a/attachment.html>

More information about the swift-evolution mailing list