> On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution
> <[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.
David
>
> - Doug
>
>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 2. Februar 2017 um 05:52:41, Douglas Gregor via swift-evolution
>> ([email protected] <mailto:[email protected]>) schrieb:
>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Feb 1, 2017, at 8:46 PM, Slava Pestov <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>>
>>>>> On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution
>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>
>>>>>>
>>>>>> On Feb 1, 2017, at 3:13 PM, David Hart <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>> Second question inline:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sent from my iPhone
>>>>>> On 1 Feb 2017, at 23:09, David Hart <[email protected]
>>>>>> <mailto:[email protected]>> 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 <[email protected]
>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Jan 29, 2017, at 8:39 AM, David Hart <[email protected]
>>>>>>>>> <mailto:[email protected]>> 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
>>>>> [email protected] <mailto:[email protected]>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
