> On Feb 9, 2017, at 2:44 PM, David Hart <da...@hartbit.com> wrote:
> 
> 
> On 9 Feb 2017, at 20:43, Matthew Johnson via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Feb 9, 2017, at 1:30 PM, Hooman Mehr via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>>> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> Looks good. Minor comments below:
>>>>> The typealias 'T5' is repeated as both an initial composition, and as a 
>>>>> demonstration of combining typealiases. 
>>>>> 
>>>>>> This proposal merges the concepts of class and AnyObject, which now have 
>>>>>> the same meaning: they represent an existential for classes. They are 
>>>>>> four solutions to this dilemna:
>>>>>> Do nothing.
>>>>>> Replace all uses of AnyObject by class, breaking source compatibility.
>>>>>> Replace all uses of class by AnyObject, breaking source compatibility.
>>>>>> Redefine AnyObject as typealias AnyObject = class.
>>>>> I agree with other comments on recommending 4 here, and covering the 
>>>>> others as alternatives
>>>>>>  
>>>>>> <https://github.com/hartbit/swift-evolution/blob/e6411d8a9e7924bbd8a48fc292bf08d58a8d1199/proposals/XXXX-subclass-existentials.md#source-compatibility>I
>>>>>>  agree that we need the typealias for compatibility. I think it's still 
>>>>>> worth discussing whether the `AnyObject` typealias should *only* be 
>>>>>> there for compatibility; it could be deprecated or obsoleted in Swift 4 
>>>>>> or future language versions.
>>> 
>>> I think it might be worth keeping to provide a more sensible capitalization 
>>> alternative than lower case “class” when used as a type name:
>>> 
>>> var obj: class // this looks weird because of capitalization.
>>> 
>>> var obj: AnyObject // this looks better.
>> 
>> I agree that it looks better and would choose AnyObject if source 
>> compatibility weren't an issue.  One option that wasn't listed was to drop 
>> 'class' but use a multi-release deprecation strategy and a fix-it to 
>> facilitate a smooth transition.  If the community is willing to adopt this 
>> approach it would be my first choice.
> 
> You mean option 3?

Pretty much, but option 3 does not make it clear that it won’t break source 
immediately in Swift 4.  I think it becomes much more reasonable if Swift 3.1 
code still compiles in Swift 4 mode, but with a deprecation warning.

The reason I prefer `AnyObject` to `class` is because I think it’s ugly to have 
`class` as the name of an existential type.  Type names are uppercase in Swift. 
 It is also used to compose with protocols which also use uppercase names in 
Swift.  Because it appears in contexts which use an uppercase convention it 
makes sense for this to have an uppercase name.  `AnyObject` seems like the 
obvious choice if we’re going to go in that direction.

> 
>>> 
>>>> 
>>>> -Joe
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to