Proposal: Change of syntax for class protocols


(Matthew Cheok) #1

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


(Joe Groff) #2

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)

-Joe

···

On Dec 7, 2015, at 8:00 AM, Matthew Cheok via swift-evolution <swift-evolution@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.


(Sean Heber) #3

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


#4

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@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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Guillaume Lessard) #5

Is using the AnyObject protocol significantly less desirable in those cases?

(It may be that you consider AnyObject to be a workaround…)

Guillaume Lessard

···

On 7 déc. 2015, at 09:58, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

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)


(Douglas Gregor) #6

Right. This is exactly the reason why we have the syntax

  protocol X : class { … }

and why I’m against changing the current syntax.

  - Doug

···

On Dec 7, 2015, at 8:58 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 7, 2015, at 8:00 AM, Matthew Cheok via swift-evolution <swift-evolution@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)


(David Owens II) #7

I rarely do.

···

On Dec 7, 2015, at 8:51 AM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:

Do others find themselves implementing class-only protocols often? They seem to be the exception, rather than the rule, to me.


(Matthew Cheok) #8

I would expect this to be somewhat common for building weakly referenced
delegates without @objc. Shouldn't this be more common in practice?

···

On Mon, Dec 7, 2015 at 8:51 AM, Stephen Celis <stephen.celis@gmail.com> 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@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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Sean Heber) #9

Rare here, too, but I don’t think that means the syntax for doing so needs to feel weird. :stuck_out_tongue:

l8r
Sean

···

On Dec 7, 2015, at 10:53 AM, David Owens II <david@owensd.io> wrote:

On Dec 7, 2015, at 8:51 AM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:

Do others find themselves implementing class-only protocols often? They seem to be the exception, rather than the rule, to me.

I rarely do.


(Riley Testut) #10

Yes, whenever I implement the delegate pattern, I have to make sure the protocol is a class protocol so I can use a weak reference.

While I use protocols for far more than just delegation, for the newer developers coming to Swift from Objective-C, the delegation pattern probably remains the most common use of protocols, so I agree we should make it as simple to use/understand as possible. +1 for the proposed syntax.

···

On Dec 7, 2015, at 9:20 AM, Matthew Cheok via swift-evolution <swift-evolution@swift.org> wrote:

I would expect this to be somewhat common for building weakly referenced delegates without @objc. Shouldn't this be more common in practice?

On Mon, Dec 7, 2015 at 8:51 AM, Stephen Celis <stephen.celis@gmail.com <mailto:stephen.celis@gmail.com>> 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Austin Zheng) #11

I prefer the original syntax. It's easier to parse at a glance that the reference is a protocol and emphasizes the primacy of the protocol, with 'class' being a modifier on the type. I do think, though, that "protocol P : class" is inconsistent with Joe's proposed "typealias TA : class" or "func<T : class>", as the list of things following "protocol P" isn't a constraint like the other two examples. So I could see a compelling reason for going either way.

Austin

···

On Dec 7, 2015, at 11:36 AM, Riley Testut via swift-evolution <swift-evolution@swift.org> wrote:

Yes, whenever I implement the delegate pattern, I have to make sure the protocol is a class protocol so I can use a weak reference.

While I use protocols for far more than just delegation, for the newer developers coming to Swift from Objective-C, the delegation pattern probably remains the most common use of protocols, so I agree we should make it as simple to use/understand as possible. +1 for the proposed syntax.

On Dec 7, 2015, at 9:20 AM, Matthew Cheok via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I would expect this to be somewhat common for building weakly referenced delegates without @objc. Shouldn't this be more common in practice?

On Mon, Dec 7, 2015 at 8:51 AM, Stephen Celis <stephen.celis@gmail.com <mailto:stephen.celis@gmail.com>> 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Groff) #12

Yeah, ': AnyObject' is more or less a workaround for ': class' not working. AnyObject should be just a typealias for the protocol<class> type.

-Joe

···

On Dec 7, 2015, at 12:49 PM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org> wrote:

On 7 déc. 2015, at 09:58, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

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)

Is using the AnyObject protocol significantly less desirable in those cases?

(It may be that you consider AnyObject to be a workaround…)


(Vivien Leroy) #13

Same here, to me it’s not the most common use. Almost feels hackish but maybe it’s related to a bias we have because we’re all trying to think more with structs and enums rather than classes because of what Swift allows us to do.

···

Le 7 déc. 2015 à 17:53, David Owens II via swift-evolution <swift-evolution@swift.org> a écrit :

On Dec 7, 2015, at 8:51 AM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:

Do others find themselves implementing class-only protocols often? They seem to be the exception, rather than the rule, to me.

I rarely do.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Felix Gabel) #14

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@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@me.com <mailto:felix.gabel@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Felix Gabel) #15

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@swift.org> wrote:

On Dec 7, 2015, at 8:58 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 7, 2015, at 8:00 AM, Matthew Cheok via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #16

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@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@swift.org> wrote:

On Dec 7, 2015, at 8:58 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 7, 2015, at 8:00 AM, Matthew Cheok via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Felix Gabel) #17

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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 7, 2015, at 8:58 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 7, 2015, at 8:00 AM, Matthew Cheok via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Daniel Valls Estella) #18

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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 7, 2015, at 8:58 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 7, 2015, at 8:00 AM, Matthew Cheok via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Daniel Valls Estella) #19

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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 7, 2015, at 8:58 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 7, 2015, at 8:00 AM, Matthew Cheok via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


#20

Doesn't the following work?

    func doSomething(localvar: protocol<MyProtocol, class>)

You could, of course, use a typealias or protocol inheritance to avoid
"protocol<...>".

···

On Tue, Dec 8, 2015 at 11:52 AM, Daniel Valls Estella via swift-evolution < swift-evolution@swift.org> 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)