Proposal: Change of syntax for class protocols

You are right, I was unaware of “inline” protocol composition. Nice!

But I didn’t found that you can specify class…

Although I’d prefer just to list required protocols spaceseparated.

I also think that it has to be explained as normal/basic option when explaining method declaration (not in protocols definition chapter).

Thanks!

···

El 8 des 2015, a les 17:55, Stephen Celis <stephen.celis@gmail.com> va escriure:

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

Doesn't the following work?

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

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

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@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@upzzle.com <mailto: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

There are such things as thread-safe data structures, e.g. message queues. Many such constructs require reference semantics for their interface to make sense. As long as the language can have reference semantics, it must be possible to restrict specific protocols to those semantics.

Guillaume Lessard

···

On 8 déc. 2015, at 10:36, Felix Gabel via swift-evolution <swift-evolution@swift.org> wrote:

A class protocol is only necessary to fulfill the requirements for a weakly referenced instance (e.g. delegate pattern).

Maybe value instances (structs, enums) could be also accepted as a valid weak reference criteria. Or in other words, maybe the weak keyword would not have to force a reference instance but define that condition in case it is.

···

El 8 des 2015, a les 18:36, Felix Gabel <felix.gabel@me.com> va escriure:

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@upzzle.com <mailto:daniel@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@upzzle.com <mailto: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