[swift-evolution] Subclass Existentials

[Matthew Johnson]

> On Feb 6, 2017, at 11:30 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 5, 2017, at 3:20 PM, David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
>> 
>> As they are heavily linked, should a change like this be included in the superclass + class proposal or separately?
>> 
>> I'm heavily tending towards (1), and redefining:
>> 
>> typealias Any = Any<>
>> typealias AnyObject = Any<class>
>> 
>> Does that sound reasonable to you? Just checking before I rewrite this proposal sometime in the next couple of days.
> 
> Tricky business; you have a proposal that’s very likely to get universal support (adding class constraints to existentials) and one that’s likely to be controversial (changing existential syntax away from what we just adopted in Swift 3). My inclination is to separate the two, because I worry that the first proposal could get swallowed up in the discussion of the second… and it gets more messy if we have to detangle one proposal into two after running the review.

+1 

> 
> 	- Doug
> 
>> 
>> David
>> 
>> On 3 Feb 2017, at 18:12, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>> 
>>> 
>>>> On Feb 2, 2017, at 3:24 PM, David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
>>>> 
>>>>> 
>>>>> On 3 Feb 2017, at 00:04, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> 
>>>>>> On Feb 2, 2017, at 2:54 PM, David Smith <david_smith at apple.com <mailto:david_smith at apple.com>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto: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.
>>>>> 
>>>>> Types can be parenthesized, so that’s a workaround. But I too have some concerns here that we’re creating an ambiguity that users will trip over.
>>>> 
>>>> On top of the ambiguity, I’m really sad that we dropped the Any<A, B, C> syntax because we lost the parallel to inheritance clauses which use the comma as separating character. They both represent similar concepts: a type inheriting and conforming and an existential represent all types which inherit and conform.
>>>> 
>>>> I’ve got to ask, is there any chance that either of the two could happen:
>>>> 
>>>> 1) Bring back the Any<A, B, C> syntax instead of A & B & C?
>>>> 2) Replace the inheritance clause X : A, B, C to X : A & B & C?
>>> 
>>> Both are possible, as is
>>> 
>>> (3) Let A & B & C be a shortcut syntax for Any<A, B, C>, such that Any<…> is the more general version that also permits where clauses, “class” constraints, etc.
>>> 
>>> Note that (2) would kill me ;)
>>> 
>>>> I know that both are severely source-breaking changes, but either of those would simplify the language by using the same syntax for two very similar concepts. Plus, number 1 would allow us to disambiguate function declarations. I know many people would rejoice having Any<> back.
>>> 
>>> Yes, they’re both significant source breakage. It’s source breakage of the “easy” kind, which only affects parsing and therefore makes it easy to keep supporting the Swift 3 syntax in Swift 4.
>>> 
>>> (3), on the other hand, isn’t a simplification at all… it’s admitting redundant syntax to avoid source breakage.
>>> 
>>> 	- 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/20170206/94984009/attachment.html>