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

Tue Dec 8 10:34:02 CST 2015

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> 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
> 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/59966d24/attachment.html>