Re: [swift-evolution] Mark protocol methods with their protocol

Hi again, Am 2016-09-27 16:51, schrieb Dave Abrahams via swift-evolution: The cases where you find these kinds of exact collisions are so rare (never in my career) that it's fine if some manual work is needed. I agree that such accidental collisions are quite rare (especially with the Swift

Re: [swift-evolution] Mark protocol methods with their protocol

Hi, Am 2016-09-27 16:51, schrieb Dave Abrahams via swift-evolution: The cases where you find these kinds of exact collisions are so rare (never in my career) that it's fine if some manual work is needed. I agree that such accidental collisions are quite rare (especially with the Swift way of

Re: [swift-evolution] Mark protocol methods with their protocol

I agree with that. I believe I have more often run into name collisions for protocols with differing semantics then matching semantics. Actually far more often then both I have purposely used somewhat contrived naming in protocols to avoid collisions, if that can be avoided by leveraging the

Re: [swift-evolution] Mark protocol methods with their protocol

on Tue Sep 27 2016, Thorsten Seitz wrote: > While this solves the problem of overlapping names with different > semantics, how would you express the case where the names actually > have the same semantics, so that you only want to have one > implementor? > > protocol A { > func

Re: [swift-evolution] Mark protocol methods with their protocol

> Am 21.09.2016 um 01:58 schrieb Karl via swift-evolution > : > > I’ve explained it so many times, do you really not understand it? > > Basically, protocols are explicit things. They are **not** things that you > just “discover” about types at all. We have protocols

Re: [swift-evolution] Mark protocol methods with their protocol

> Am 23.09.2016 um 12:47 schrieb Vladimir.S : > >> On 23.09.2016 11:05, Maximilian Hünenberger wrote: >> I'd also say that one or two keywords are superior than the protocol naming >> approach in terms of implementation simplicity (for the core team). >> >> My suggestions: >>

Re: [swift-evolution] Mark protocol methods with their protocol

> On 23 Sep 2016, at 18:25, Vladimir.S wrote: > > On 23.09.2016 17:41, Rien wrote: >> Hello Vladimir, >> >> Going back to the original suggestion: >> >> /4.1 Different implementation for different protocols/ >> /class Foo : ProtocolA, ProtocolB {/ >> / implement(ProtocolA)

Re: [swift-evolution] Mark protocol methods with their protocol

On 23.09.2016 17:41, Rien wrote: Hello Vladimir, Going back to the original suggestion: /4.1 Different implementation for different protocols/ /class Foo : ProtocolA, ProtocolB {/ / implement(ProtocolA) func foo() {...}/ / implement(ProtocolB) func foo() {...}/ /}/ /class Foo : ProtocolA,

Re: [swift-evolution] Mark protocol methods with their protocol

Hello Vladimir, Going back to the original suggestion: 4.1 Different implementation for different protocols class Foo : ProtocolA, ProtocolB { implement(ProtocolA) func foo() {...} implement(ProtocolB) func foo() {...} } class Foo : ProtocolA, ProtocolB { implement ProtocolA {

Re: [swift-evolution] Mark protocol methods with their protocol

Hello Martin, Adding protocol conformance via existing functions can be had in different ways, first it could be done via mapping rules. I.e. if the API user requests a function A.Foo.foo() and there is only a function A.foo() present, the language rules could allow this to be accepted as the

Re: [swift-evolution] Mark protocol methods with their protocol

On 23.09.2016 15:10, Rien wrote: Note: Second attempt, first mail was rejected ? That is correct Vladimir, at the point of writing an API you never know who will end up using it in which way. Hence the decision which flavour (of a function) to call should not be made by the coder writing the

Re: [swift-evolution] Mark protocol methods with their protocol

Hello :) Am 2016-09-23 08:50, schrieb Rien: > -- module A -- > class A { > func foo() {} > } > > -- module B -- > protocol Foo { > func foo() > } > extension A: Foo {} let c = A() I’d say that you have two functions here: A.foo() and A.Foo.foo() No. Now (i.e. within module B) A

Re: [swift-evolution] Mark protocol methods with their protocol

Note: Second attempt, first mail was rejected ? That is correct Vladimir, at the point of writing an API you never know who will end up using it in which way. Hence the decision which flavour (of a function) to call should not be made by the coder writing the API but by the coder using the API.

Re: [swift-evolution] Mark protocol methods with their protocol

On 23.09.2016 11:05, Maximilian Hünenberger wrote: I'd also say that one or two keywords are superior than the protocol naming approach in terms of implementation simplicity (for the core team). My suggestions: Either "conform" or "implement" should be a required keyword for all

Re: [swift-evolution] Mark protocol methods with their protocol

I'd also say that one or two keywords are superior than the protocol naming approach in terms of implementation simplicity (for the core team). My suggestions: Either "conform" or "implement" should be a required keyword for all properties/functions which implement a protocol (also in protocol

Re: [swift-evolution] Mark protocol methods with their protocol

It took another good night’s sleep to be able to realise what I really wanted to express yesterday. It comes down to three points: 1) Protocol marking is not really a proposal, but a bug report. 2) I do not think it needs new syntax 3) There is probably a lot of code out there that “uses” this

Re: [swift-evolution] Mark protocol methods with their protocol

on Thu Sep 22 2016, Martin Waitz wrote: > Hi, > > isn't it perfectly fine to conform to multiple unrelated protocols > which both require the same member? Yeah, but in practice it *basically* never happens, to the point where I'd be fine requiring boilerplate repetition if you wanted to

Re: [swift-evolution] Mark protocol methods with their protocol

Extensions in Swift aren't a first-class entity; they have no name and no representation in the type system. If an extension to A does something, then A does something. If A conforms to P, then A.foo is the implementation of P.foo. On Thu, Sep 22, 2016 at 11:06 Marinus van der Lugt via

Re: [swift-evolution] Mark protocol methods with their protocol

That does not seem right to me. A does not implement any protocol. The extension of A implements a protocol thus foo() should not be seen as part of the protocol at all. So far, I have always extended a class when adding protocol compliance. I.e. it is always clear I.e. protocol P { func

Re: [swift-evolution] Mark protocol methods with their protocol

On 22.09.2016 11:10, Jean-Denis Muys via swift-evolution wrote: I watched this thread with a lot of attention, starting neutral. You must say that Karl won me over. His proposal would make Swift more expressive, and less error prone in cases of protocol conformance with name collisions. I am at

Re: [swift-evolution] Mark protocol methods with their protocol

On 22.09.2016 7:46, Russ Bishop via swift-evolution wrote: On Sep 20, 2016, at 4:34 PM, Dave Abrahams via swift-evolution wrote: on Tue Sep 20 2016, Karl wrote: I think the best way is to prefix the member name with the protocol, e.g: protocol MyProto { var

Re: [swift-evolution] Mark protocol methods with their protocol

Hi, isn't it perfectly fine to conform to multiple unrelated protocols which both require the same member? Or to declare protocol conformance in some unrelated module? Am 2016-09-22 07:15, schrieb Karl via swift-evolution: I would like to make it a requirement if not inside a protocol

Re: [swift-evolution] Mark protocol methods with their protocol

I watched this thread with a lot of attention, starting neutral. You must say that Karl won me over. His proposal would make Swift more expressive, and less error prone in cases of protocol conformance with name collisions. I am at this point +1 Jean-Denis Sent from my iPhone > On 22 Sep

Re: [swift-evolution] Mark protocol methods with their protocol

I would like to make it a requirement if not inside a protocol extension which declares a conformance, and actually build the protocol name in to the member in an ABI-breaking way. We could make it additive by generating forwarding thunks from the old symbols to the new ones, but it would be

Re: [swift-evolution] Mark protocol methods with their protocol

> On Sep 20, 2016, at 4:34 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Sep 20 2016, Karl wrote: > >> I think the best way is to prefix the member name with the protocol, e.g: >> >> protocol MyProto { >>var aVariable : Int >>func

Re: [swift-evolution] Mark protocol methods with their protocol

On 21.09.2016 2:34, Dave Abrahams via swift-evolution wrote: on Tue Sep 20 2016, Karl wrote: I think the best way is to prefix the member name with the protocol, e.g: protocol MyProto { var aVariable : Int func aFunction() } class MyClass : MyProto { var MyProto.aVariable : Int

Re: [swift-evolution] Mark protocol methods with their protocol

Sorry if that sounds a little bit rude, I’ve been switching between English and German a lot and the way you speak in one language can come across wrong in another! > On 21 Sep 2016, at 01:58, Karl wrote: > > I’ve explained it so many times, do you really not

Re: [swift-evolution] Mark protocol methods with their protocol

I’ve explained it so many times, do you really not understand it? Basically, protocols are explicit things. They are **not** things that you just “discover” about types at all. We have protocols with no members (“marker protocols”) which are basically used to tag certain types with no other

Re: [swift-evolution] Mark protocol methods with their protocol

on Tue Sep 20 2016, Karl wrote: > I think the best way is to prefix the member name with the protocol, e.g: > > protocol MyProto { > var aVariable : Int > func aFunction() > } > class MyClass : MyProto { > var MyProto.aVariable : Int > func MyProto.aFunction() { … } > } ... >

Re: [swift-evolution] Mark protocol methods with their protocol

This was the conversation we were having in the other thread. Perhaps I'm still not understanding something, but I'm not convinced that this feature is an improvement. Currently, protocols represent a declaration that you have discovered that your type has certain semantics and guarantees a

Re: [swift-evolution] Mark protocol methods with their protocol

I’m using String as an example of where this issue of conformance conflicts crops up in the standard library. Ideally, String (or any data type) should be able to conform to protocols whose requirements have conflicting names. Currently, in order to work around this limitation, you have to

Re: [swift-evolution] Mark protocol methods with their protocol

Sorry, I'm still not sure I understand what you're getting at about this. How would String conforming to Collection multiple times simplify or improve the implementation of String? Or are you arguing it would be better for users of String? If so, how? On Tue, Sep 20, 2016 at 17:26 Karl

Re: [swift-evolution] Mark protocol methods with their protocol

> On 21 Sep 2016, at 00:08, Vladimir.S wrote: > > On 21.09.2016 0:28, Karl via swift-evolution wrote: >> > > I don't understand. Do you feel that this: > > class MyClass : MyProto { >var MyProto.aVariable : Int >func MyProto.aFunction() { … } > } > > better than

Re: [swift-evolution] Mark protocol methods with their protocol

I’m not saying vital support is missing, just that it is more awkward. String doesn’t conform to collection, String.UTF8View does; so if you change some implementation detail (in StringCore, because that’s where they live for String), you get the error popping up somewhere other than the place

Re: [swift-evolution] Mark protocol methods with their protocol

On 21.09.2016 0:28, Karl via swift-evolution wrote: I don't understand. Do you feel that this: class MyClass : MyProto { var MyProto.aVariable : Int func MyProto.aFunction() { … } } better than this: class MyClass : MyProto { implement var aVariable : Int implement func

Re: [swift-evolution] Mark protocol methods with their protocol

On 20.09.2016 19:43, Nevin Brackett-Rozinsky via swift-evolution wrote: I have been following this discussion (as well as similar threads earlier this year) and listening to the ideas put forth by all sides. Yes, to do nothing and to have fragile protocol oriented programming is an another

Re: [swift-evolution] Mark protocol methods with their protocol

On 20.09.2016 19:03, Charles Srstka wrote: On Sep 20, 2016, at 10:56 AM, Vladimir.S via swift-evolution > wrote: Then, shouldn't we disallow protocol conformance 'in-place' in type's definition? So, if you need to conform to protocol

Re: [swift-evolution] Mark protocol methods with their protocol

I'm not sure I understand. What compiler or language support is missing for StringCore? On Tue, Sep 20, 2016 at 16:42 Karl via swift-evolution < swift-evolution@swift.org> wrote: > On 20 Sep 2016, at 23:28, Karl wrote: > > > On 20 Sep 2016, at 18:43, Nevin

Re: [swift-evolution] Mark protocol methods with their protocol

> On 20 Sep 2016, at 23:28, Karl wrote: > > >> On 20 Sep 2016, at 18:43, Nevin Brackett-Rozinsky via swift-evolution >> > wrote: >> >> I have been following this discussion (as well as similar threads

Re: [swift-evolution] Mark protocol methods with their protocol

> On 20 Sep 2016, at 18:43, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > I have been following this discussion (as well as similar threads earlier > this year) and listening to the ideas put forth by all sides. > > It seems to me that the fundamental

Re: [swift-evolution] Mark protocol methods with their protocol

I have been following this discussion (as well as similar threads earlier this year) and listening to the ideas put forth by all sides. It seems to me that the fundamental difference between classes and protocols is that classes inherit implementation whereas protocol conformance is a promise

Re: [swift-evolution] Mark protocol methods with their protocol

> On Sep 20, 2016, at 10:56 AM, Vladimir.S via swift-evolution > wrote: > > Then, shouldn't we disallow protocol conformance 'in-place' in type's > definition? So, if you need to conform to protocol - only extension is the > syntax for this. In this case I can

Re: [swift-evolution] Mark protocol methods with their protocol

On 20.09.2016 17:48, Martin Waitz wrote: Hello everybody, Several suggestions are floating around about explicitly marking a method to implement a protocol requirement. E.g.: class Foo : Bar { implement func foo() {...} } However, with extensions we can already do something very

Re: [swift-evolution] Mark protocol methods with their protocol

+1. This is the cleanest proposed solution I've seen to this problem. Like many people, I've started breaking up a lot of my large classes like view controllers that have multiple protocol conformances into separate extensions, and this would let many of those diagnostics fall out naturally. On

Re: [swift-evolution] Mark protocol methods with their protocol

As I mentioned above, I agree that better diagnostics for near-misses are necessary, but they are possible without new syntax. There is no win in avoiding unintentional behavior because, without a default implementation, these issues are caught at compile time already. On Tue, Sep 20, 2016 at

Re: [swift-evolution] Mark protocol methods with their protocol

I think that's a simple and elegant solution. The private member exception can be extended so that any member with less visibility than the minimum of the type and protocol visibility would be allowed. On Tue, Sep 20, 2016 at 09:48 Martin Waitz wrote: > Hello everybody, > >

Re: [swift-evolution] Mark protocol methods with their protocol

Hello everybody, Several suggestions are floating around about explicitly marking a method to implement a protocol requirement. E.g.: class Foo : Bar { implement func foo() {...} } However, with extensions we can already do something very similar: class Foo { }

Re: [swift-evolution] Mark protocol methods with their protocol

> On Sep 20, 2016, at 8:17 AM, Vladimir.S via swift-evolution > wrote: > > On 20.09.2016 3:03, Xiaodi Wu via swift-evolution wrote: >> I definitely think Vladimir's suggestion is a great starting point, IMO. >> >> However, I think it could be improved in one key

Re: [swift-evolution] Mark protocol methods with their protocol

Inline.. On 20.09.2016 3:03, Xiaodi Wu via swift-evolution wrote: I definitely think Vladimir's suggestion is a great starting point, IMO. However, I think it could be improved in one key respect where previous proposals using `override` are superior. Namely, the proposed `implement` keyword

Re: [swift-evolution] Mark protocol methods with their protocol

> On 20 Sep 2016, at 02:25, Xiaodi Wu via swift-evolution > wrote: > >> On Mon, Sep 19, 2016 at 7:15 PM, Boris Wang wrote: >> I don't think "override" is a good idea. It's not overriding. >> >> Protocol is not Class. >> > > I think you make a

Re: [swift-evolution] Mark protocol methods with their protocol

On Mon, Sep 19, 2016 at 7:15 PM, Boris Wang wrote: > I don't think "override" is a good idea. It's not overriding. > > Protocol is not Class. > I think you make a good point. It seems like people have generally written about "overriding" default implementations, but that

Re: [swift-evolution] Mark protocol methods with their protocol

I don't think "override" is a good idea. It's not overriding. Protocol is not Class. Xiaodi Wu via swift-evolution 于2016年9月20日 周二08:04写道： > I definitely think Vladimir's suggestion is a great starting point, IMO. > > However, I think it could be improved in one key

Re: [swift-evolution] Mark protocol methods with their protocol

I definitely think Vladimir's suggestion is a great starting point, IMO. However, I think it could be improved in one key respect where previous proposals using `override` are superior. Namely, the proposed `implement` keyword adds no additional safety when a type implements a protocol

Re: [swift-evolution] Mark protocol methods with their protocol

+1 Sent from my iPhone > On 19 Sep 2016, at 18:10, Vladimir.S via swift-evolution > wrote: > >> On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote: >> >> Let me give a concrete example of how retroactively modeling is used. > > Karl is suggesting interesting

Re: [swift-evolution] Mark protocol methods with their protocol

If Swift 4 will make it impossible to tackle this again, I do not think discussing this can be avoided for Swift 3.1... I am afraid we are rushing into Swift 4 a bit too quickly, but perhaps it is just silly old me :). Sent from my iPhone > On 19 Sep 2016, at 19:18, Charles Srstka via

Re: [swift-evolution] Mark protocol methods with their protocol

> On Sep 19, 2016, at 12:10 PM, Vladimir.S via swift-evolution > wrote: > > On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote: >> >> Let me give a concrete example of how retroactively modeling is used. > > Karl is suggesting interesting but complex and IMO

Re: [swift-evolution] Mark protocol methods with their protocol

I started putting together a proposal, hopefully better explaining what I’m suggesting: https://github.com/karwa/swift-evolution/blob/patch-2/-template.md > On 17 Sep 2016, at 05:32, Xiaodi Wu

Re: [swift-evolution] Mark protocol methods with their protocol

> On 17 Sep 2016, at 05:32, Xiaodi Wu wrote: > > On Fri, Sep 16, 2016 at 20:28 Karl > wrote: >> On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution >> >

Re: [swift-evolution] Mark protocol methods with their protocol

On Fri, Sep 16, 2016 at 20:28 Karl wrote: > On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I absolutely agree that it's a problem worth solving. However, the > question is whether a particular proposed design solves the

Re: [swift-evolution] Mark protocol methods with their protocol

> On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution > wrote: > > I absolutely agree that it's a problem worth solving. However, the question > is whether a particular proposed design solves the problem and avoids > previously stated weaknesses. What I'm

Re: [swift-evolution] Mark protocol methods with their protocol

I'm not familiar with all of the discussions in other threads relating to this issue that some are here, so forgive me if I'm running over old ground. Looking back at the original use case that David B. posted my first instinct was that this is a case that would best be solved by adding a

Re: [swift-evolution] Mark protocol methods with their protocol

Yeah, I figured it had probably come up before since I don’t follow evolution that closely, but it is, in my opinion and experience, Swift’s last pitfall. So many other pitfalls from ObjC and other languages have been solved with Swift, including this exact one (when it comes to subclassing).

Re: [swift-evolution] Mark protocol methods with their protocol

On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution wrote: > > We've had this discussion on the list multiple times already. The gist of the > difficulty here is that most proposals for a mandatory keyword don't permit > retroactive modeling, so it's a no-go.

Re: [swift-evolution] Mark protocol methods with their protocol

We've had this discussion on the list multiple times already. The gist of the difficulty here is that most proposals for a mandatory keyword don't permit retroactive modeling, so it's a no-go. On the other hand, the core team seems to take a dim view to optional syntax, since that's more in the

Re: [swift-evolution] Mark protocol methods with their protocol

I don’t really like the idea of override(ProtocolName), but I’d support the single override here. On value types it’s easier to recognize the member of a protocol which had a default implementation. I don’t feel like adding override to all members that replaces some default implementation will

Re: [swift-evolution] Mark protocol methods with their protocol

David, thank you for a real-word example when such feature will be very useful and can protect from hard-to-find bugs. IMO This shows that we should find a solution for the problem as soon as possible. Such or similar question was discussed already in an number of threads, for example in