> On Feb 2, 2017, at 2:54 PM, David Smith <[email protected]> wrote:
>
>>
>> On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev
>>> <[email protected] <mailto:[email protected]>>
>>> 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.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
