> On Feb 1, 2017, at 3:13 PM, David Hart <[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.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
