[swift-evolution] Proposal: Change of syntax for class protocols

[Felix Gabel]

I can only think of one use case for restricting a protocol to be only conformable by structs or enums and that is their special behavior for 'willSet’ and ‘didSet’. But this is already discussed in another thread. 

It boils down to this: The sole purpose for a class protocol is its memory management semantics.


> On Dec 8, 2015, at 7:43 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Lets say (and hope) in some future we’ll be able to write functions like this:
> 
> func foo<T: class>(_: T) { /* do something */ }
> func foo<T: enum>(_: T) { /* do something */ }
> func foo<T: struct>(_: T) { /* do something */ }
> 
> // or we might want to have more than one generic types
> 
> func foo<A: class, B: enum, C: struct>(_: A, _: B, _: C) {
>     // do something better
> }
> 
> // try to use `where` clause with `class A`, `struct C`. It looks ugly to me.
> So ins’t it better to stick to the original syntax and write code like this!?
> 
> protocol MagicType {} // can be applied to any type
> protocol ClassType: class {} // only for classes
> protocol StructType: struct {} only for structs
> protocol ValueType: struct, enum {}  
> protocol MixedType: struct, class {}
> This is why in my eyes the current syntax for protocols is just perfect.
> 
> 
> 
> 
> — 
> Regards Adrian
> 
> Am 7. Dezember 2015 bei 23:29:34, Felix Gabel via swift-evolution (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) schrieb:
> 
>> Great to hear about being able to apply this to type parameters and associated types in the future. But I still propose to rethink the syntax decision. 
>>  
>> class protocol FooType {}
>> typealias class Bar: FooType
>> func foo<class T>()
>> 
>> This is more consistent with for example the declaration of a class or property
>> 
>> Construct name: Type
>> 
>> On 07 Dec 2015, at 23:04, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>>> On Dec 7, 2015, at 8:58 AM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> 
>>>>> On Dec 7, 2015, at 8:00 AM, Matthew Cheok via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> Currently, we declare class protocols with the following syntax:
>>>>> 
>>>>> protocol TestProtocol: class, OtherProtocol {}
>>>>> 
>>>>> This is odd for a few reasons:
>>>>> 1) The keyword class exists in the middle of the declaration
>>>>> 2) The keyword class follows the colon and looks a lot like inheritance
>>>>> 3) The keyword class occupies a somewhat arbitrary first position after the colon (otherwise we have an error)
>>>>> 
>>>>> We also have another use of the class keyword as a modifier when declaring class methods:
>>>>> 
>>>>> class func doSomething() {}
>>>>> 
>>>>> I’m suggesting a change of syntax that rectifies the above issues:
>>>>> 
>>>>> class protocol TestProtocol: OtherProtocol {}
>>>>> 
>>>>> Would love to hear other thoughts on this.
>>>> 
>>>> The constraint syntax is used because, in the fullness of time, it should also be applicable to type parameters and associated types:
>>>> 
>>>> protocol Foo { typealias T: class }
>>>> 
>>>> func foo<T: class>(x: T)
>>> 
>>> 
>>> Right. This is exactly the reason why we have the syntax
>>> 
>>> protocol X : class { … }
>>> 
>>> and why I’m against changing the current syntax.
>>> 
>>> - Doug
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151208/0770db54/attachment.html>