Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

> I am not sure why protocol extension need to differ so much and present dispatch rules that are potentially very confusing. I think that both the Java and Swift designers want to get the benefits of multiple inherences, in the meaning time, they don't want to support multiple objects inherence.

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

I understand your point on "adding additional `override` to re-implementation of default method in protocol extension". However, I don't stand for it. If you use `override`, that means `B` could use `super.bar()` to get the original `bar()` implementation. Then if `class A` implement `bar()`

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] [swift-dev] Rebinding UnsafePointer makes it mutable

> On Sep 19, 2016, at 11:44 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Sep 19 2016, Andrew Trick wrote: > >>> On Sep 19, 2016, at 1:24 AM, Martin R via swift-dev >>> wrote: >>> >>> I noticed that

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

This would make for hilarious debugging session if you have the misfortune of using a third party binary framework that gets updated and provide default implementations for some methods in the protocol extensions. When Java 8 also decided to blur the lines between classes (implementations) and

Re: [swift-evolution] [Pitch] Align label behavior for subscripts

It sounds like they were a joy to handle under the hood... yikes ;). Sent from my iPhone > On 20 Sep 2016, at 16:42, Douglas Gregor via swift-evolution > wrote: > > >> On Sep 20, 2016, at 3:36 AM, Adrian Zubarev via swift-evolution >>

Re: [swift-evolution] [Pitch] Align label behavior for subscripts

> On Sep 20, 2016, at 5:42 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Sep 20, 2016, at 3:36 AM, Adrian Zubarev via swift-evolution >> wrote: >> >> This is probably something additional and it might already have been >>

Re: [swift-evolution] generic associatedtype?

And a simple example of what the code might look like when using it: https://gist.github.com/anonymous/790a690597069fe70b8c874a042d52d0 On Tue, Sep 20, 2016 at 6:47 PM, Jens Persson wrote: > Here's the code for the little meta-programming tool, SwiftInSwift: >

Re: [swift-evolution] generic associatedtype?

Here's the code for the little meta-programming tool, SwiftInSwift: https://gist.github.com/anonymous/07d9df1a80820bb5abf5a2c671fd223f /Jens On Tue, Sep 20, 2016 at 6:28 PM, Jens Persson wrote: > You can put DEF-blocks and PRINT-blocks in your code, eg: > > // DEF-{ > func

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] generic associatedtype?

You can put DEF-blocks and PRINT-blocks in your code, eg: // DEF-{ func generateSomeCode() -> [String] { var linesOfCode = [String]() // ... fill linesOfCode with some interesting code ... return linesOfCode } // }-DEF // PRINT-{ generateSomeCode() // The result of the

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] [Pitch] Align label behavior for subscripts

I agree, no obvious win to revisiting, best to keep source compatibility. On Tue, Sep 20, 2016 at 10:43 Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > On Sep 20, 2016, at 3:36 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote: > > This is

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] [Pitch] Align label behavior for subscripts

> On Sep 20, 2016, at 3:36 AM, Adrian Zubarev via swift-evolution > wrote: > > This is probably something additional and it might already have been > discussed here somewhere, I apologize if I missed that talk. > > The rule for parameter labels on functions was

Re: [swift-evolution] [swift-users] Problem with COW optimization

on Tue Sep 20 2016, Adrian Zubarev wrote: > True, but how do you traverse back the tree from an inner node? > > Lets look at this simple tree: > > > > > > > let second = /* get the second node */ > > second.parent // <— How would you implement this

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

I think there is a deeper issue that may be worth exploring here. Notably, when one class presents a member function, its subclasses ought to use “override” when they reimplement that method themselves, regardless of where the superclass’s version comes from. In the original post, the class “A”

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] generic associatedtype?

On 20.09.2016 16:43, Jens Persson via swift-evolution wrote: Sure, but the reason to go for C++ in this case would only be to be able to use eg its templates and constexprs, things that doesn't translate well into Swift. And I think it's a long term goal of Swift to become a systems language.

Re: [swift-evolution] generic associatedtype?

Sure, but the reason to go for C++ in this case would only be to be able to use eg its templates and constexprs, things that doesn't translate well into Swift. And I think it's a long term goal of Swift to become a systems language. We ended up making a meta-programming-tool that we use as a

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

[swift-evolution] [Pitch] Align label behavior for subscripts

This is probably something additional and it might already have been discussed here somewhere, I apologize if I missed that talk. The rule for parameter labels on functions was fixed in Swift, but now it kinda feels odd to have a different pair of rules for subscripts (at least it does feel

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] [swift-users] [swift-user]Unexpected behavior of protocol extension.

I can’t tell you the reason, but to me it feels like it’s doing the following thing: + - - (Type: B) - - + | | | func bar()+ - + (Type: A) - - +< - - - - - - - - - - - - - - - - - - - - + | | |

Re: [swift-evolution] [swift-users] Problem with COW optimization

One note about the cloning: var root = XML.Element(name: "root") var first = XML.Element(name: "first") var second = XML.Element(name: "second") first.add(second) root[first][second].add(root) // Lets say we don't clone here anything In that scenario we would add root as the

Re: [swift-evolution] [swift-users] Problem with COW optimization

True, but how do you traverse back the tree from an inner node? Lets look at this simple tree: let second = /* get the second node */ second.parent // <— How would you implement this with pure value type? If parent were only a struct without a reference type behind the scenes

Re: [swift-evolution] [swift-users] Problem with COW optimization

on Mon Sep 19 2016, Adrian Zubarev wrote: > I think I just found a solution to my problem: > > /// - Parameter child: The new `child` to add to the `children` array. > public mutating func add(_ child: Element) { > >let clonedChildReference = Reference(cloning:

Re: [swift-evolution] [swift-dev] Rebinding UnsafePointer makes it mutable

on Mon Sep 19 2016, Andrew Trick wrote: >> On Sep 19, 2016, at 1:24 AM, Martin R via swift-dev >> wrote: >> >> I noticed that both UnsafePointer and UnsafeMutablePointer have the >> identical method >> >>public func withMemoryRebound