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

Tue Dec 8 10:52:03 CST 2015

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> 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
> 

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