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

Tue Dec 8 11:36:15 CST 2015

I like the idea of separating memory semantics and protocol declaration but this solution is not scalable. Implementing one function like that is feasible but having to implement 20 or more introduces a lot of overhead. A class protocol is only necessary to fulfill the requirements for a weakly referenced instance (e.g. delegate pattern).

> On Dec 8, 2015, at 5:52 PM, Daniel Valls Estella <daniel at upzzle.com> wrote:
> 
> Just to clarify.
> 
> I think maybe it’s better to move away class constrain from protocol definitions 
> and enable such type of restriction when requesting elements alongside with type/protocol conformance requirements.
> 
> func doSomething(localvar: MyProtocol class){
> 
> 	
> }
> 
> 
>> El 8 des 2015, a les 17:34, Daniel Valls Estella <daniel at upzzle.com <mailto:daniel at upzzle.com>> va escriure:
>> 
>> Maybe the restriction of being a class wouldn’t have to do anyting in the protocol definition and it is more a concern of who is managing an element (conforming that protocols and some others).
>> 
>> Avoiding  protocol modifiers and then when using it and if needed:
>> 
>> func doSomething(localvar: MyProtocol class){
>> 
>> 	
>> }
>> 
>> 
>> In fact, if it will be constrained that way in other situations:
>> 
>>>>>>> protocol Foo { typealias T: class }
>>>>>>> 
>>>>>>> func foo<T: class>(x: T)
>> 
>> I understant T can also be a protocol no only a concrete implementation, a class.
>> 
>> 
>> In that way, and it’s another branch to talk about, perhaps it is desirable to constrain method parameters to more than one protocol at a time. 
>> 
>> func doSomething(localvar: MyProtocol Equatable){
>> 
>> 	
>> }
>> 
>> 
>> 
>>> El 8 des 2015, a les 10:56, Felix Gabel via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> va escriure:
>>> 
>>> 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 <mailto: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>
>>> 
>>> 
>>> _______________________________________________
>>> 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/90c67ebe/attachment.html>