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

Felix Gabel felix.gabel at me.com
Mon Dec 7 11:13:20 CST 2015


I agree that this is a necessity, but mixing type requirements with a construct limitation should not be the way forward. To take your example I would try to separate those informations by doing:

typealias class T: FooType

I myself don’t have a perfect solution for the case of multiple protocol conformance except for creating a wrapper protocol that incorporates all required protocols


> On Dec 7, 2015, at 6:02 PM, Stephen Celis <stephen.celis at gmail.com> wrote:
> 
> Ah, given what Joe mentioned (`typealias T: class`, `<T: class>`), it actually makes a lot of sense given `protocol<…>`.
> 
> Stephen
> 
> On Mon, Dec 7, 2015 at 11:58 AM, Felix Gabel <felix.gabel at me.com <mailto:felix.gabel at me.com>> wrote:
> Every time you want to implement Delegates it will be a requirement that your delegate property is a weak optional that conforms to that protocol. This already implicitly enforces that the protocol is a class protocol. I personally don’t like this implicit notion and would personally prefer a protocol explicitly declared as a class protocol. 
> 
> Therefore +1 from my side for:
> 
> class protocol Foo {}
> class protocol Bar : Foo {}
> 
> 
>> On Dec 7, 2015, at 5:51 PM, Stephen Celis via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Do others find themselves implementing class-only protocols often? They seem to be the exception, rather than the rule, to me.
>> 
>> Stephen
>> 
>> On Mon, Dec 7, 2015 at 11:32 AM, Sean Heber via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I found this odd, too. I don’t know what kind of parsing ramifications this might have, but I like the idea. I suppose one downside is that it makes protocols for classes seem somehow special or different from other protocols - but then again, they kind of are!
>> 
>> l8r
>> Sean
>> 
>> 
>> > On Dec 7, 2015, at 10: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.
>> >
>> > - Matthew
>> >
>> > _______________________________________________
>> > 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/20151207/6b4a9a7e/attachment.html>


More information about the swift-evolution mailing list