Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I'm thinking about this.. but first, could someone *please* describe(clarify) the behavior of the next code and if that behavior is expected and if we really need exactly this behavior and if we can(I mean if it is not too hard) change this.. : protocol A { } extension A { func a() {

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

The pitch was not warmly received. If you want to pick it up and run with it, go ahead. https://gist.github.com/erica/fc66e6f6335750d737e5512797e8284a I have a running list of dead or deferred ideas here:

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Hi Erica, could you clarify, what is state of this proposal and your plans regarding it? I believe we certainly should make Swift more explicit regarding what methods in type are required by the conformed protocol and what methods are required(and which are 'optional') in protocol extensions.

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

on Fri Apr 29 2016, Matthew Judge wrote: > I believe the following idea was brought up on the list the last time > this topic came up, but I think it has a number of advantages and gets > rid of the need for a 'required' keyword completely. I have > reservations on

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 30, 2016, at 10:19 AM, T.J. Usiyan via swift-evolution > wrote: > > I agree that a keyword indicating intent would be nice, but I can't get > behind override if what you're doing is providing your own implementation. I > understand that we are trying to

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I agree that a keyword indicating intent would be nice, but I can't get behind override if what you're doing is providing your own implementation. I understand that we are trying to avoid adding keywords but could `implement` or a synonym work? If you override something that your superclass

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I like your example because it focusses on the scenarios I often have to deal with: namely to inherit working code that is lacking flexibility and/or abstraction (extensibility). Then I have to find convoluted ways to retrofit some abstractions that do not alter the original code, but let me

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 28, 2016, at 8:09 PM, Erica Sadun via swift-evolution > wrote: > > Sorry, that's not my question, which doesn't involve protocols I don't own. > Let me restate. Given three types I don't own as follows: > > ``` > struct A : Frobnicate { > override

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I believe the following idea was brought up on the list the last time this topic came up, but I think it has a number of advantages and gets rid of the need for a 'required' keyword completely. I have reservations on the 'override' keyword as well, but the following idea would not preclude

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I'd be keenly interested in something that would improve the experience of conforming a type to a protocol. I think others would as well. A sufficiently sophisticated solution would: * catch unintentional typos that cause required functions to be incorrectly named * show, ideally prospectively,

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

On Apr 28, 2016, at 10:00 PM, Jordan Rose wrote: > Hi, Erica. Sorry for not participating in the first round here. I’m…not so > happy with this direction, for a number of reasons. (I apologize for the > laundry list, but they’re not really related complaints.) > > -

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 28, 2016, at 20:51, Erica Sadun via swift-evolution > wrote: > > >> On Apr 28, 2016, at 6:44 PM, Andrew Bennett wrote: >> >> Hey, what annotations would I have in this case: >> >> Module 1: >> Type AType { func foo() { ... } } >>

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[resending without quoting the proposal, because apparently that made Mail emit garbage today] Hi, Erica. Sorry for not participating in the first round here. I’m…not so happy with this direction, for a number of reasons. (I apologize for the laundry list, but they’re not really related

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Hi, Erica. Sorry for not participating in the first round here. I’m…not so happy with this direction, for a number of reasons. (I apologize for the laundry list, but they’re not really related complaints.) - ‘required’ already means something today: it means “this initializer must be present

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

On Thu, Apr 28, 2016 at 9:53 PM, Erica Sadun wrote: > > On Apr 28, 2016, at 8:46 PM, Xiaodi Wu wrote: > Let's return to the toy example. Suppose I license the following code from > a third party. I am allowed to incorporate it unmodified into my

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 28, 2016, at 8:46 PM, Xiaodi Wu wrote: > Let's return to the toy example. Suppose I license the following code from a > third party. I am allowed to incorporate it unmodified into my project: > > ``` > // I cannot touch any of the following code > struct A { >

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

On Thu, Apr 28, 2016 at 9:40 PM, Erica Sadun wrote: > > Without actually trying to understand the details of your math stuff: > > * If you add a required member in a declaration or extension that declares > conformance, it is 'required'. > * If it is already defaulted, it is

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 28, 2016, at 8:25 PM, Erica Sadun via swift-evolution > wrote: > > On Apr 28, 2016, at 8:11 PM, Xiaodi Wu > wrote: >> >> Sorry, stripped out a little too much, I guess. Let me expand a little: >> >> In

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

On Thu, Apr 28, 2016 at 9:25 PM, Erica Sadun wrote: > On Apr 28, 2016, at 8:11 PM, Xiaodi Wu wrote: > > > Sorry, stripped out a little too much, I guess. Let me expand a little: > > In this example, `PortedTransform` has, by virtue of how it works, an

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

My bad for such a convoluted example. All of this is trying to say something rather simple: I'm sure almost all of you who've worked with C++ have used Boost header-only libraries. Many of them are really nice. There are reasons why third-party Swift code might be distributed by one person and

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

On Apr 28, 2016, at 8:11 PM, Xiaodi Wu wrote: > > Sorry, stripped out a little too much, I guess. Let me expand a little: > > In this example, `PortedTransform` has, by virtue of how it works, an upper > bound and lower bound for valid input (among other interesting

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

On Thu, Apr 28, 2016 at 8:32 PM, Erica Sadun wrote: > > On Apr 28, 2016, at 6:20 PM, Xiaodi Wu wrote: > > On Thu, Apr 28, 2016 at 6:44 PM, Erica Sadun wrote: > >> Can you give me a specific example of where this approach fails

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Thanks for clarifying, my responses are inline. On Fri, Apr 29, 2016 at 10:51 AM, Erica Sadun wrote: > > On Apr 28, 2016, at 6:44 PM, Andrew Bennett wrote: > > Hey, what annotations would I have in this case: > > Module 1: > > Type AType { func foo() {

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

On Thu, Apr 28, 2016 at 6:44 PM, Erica Sadun wrote: > Can you give me a specific example of where this approach fails for you? > > -- E > Sure, I'll describe one (renaming some things for clarity and stripping out the meat of the code, because it's not relevant and

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Sent from my iPad > On Apr 28, 2016, at 6:20 PM, Erica Sadun wrote: > > >>> On Friday, 29 April 2016, Matthew Johnson via swift-evolution >>> wrote: >>> Does that mean the conformance declaration will be accepted by the compiler >>> under

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Why allow both `override` and `required`? I understand you mean it to indicate that you're overriding a requirement, but does that provide any additional safety? Both say "I intend to name something the same as something else." In addition, the juxtaposition of both keywords can be misunderstood.

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Can you give me a specific example of where this approach fails for you? -- E > On Apr 28, 2016, at 5:24 PM, Xiaodi Wu via swift-evolution > wrote: > > I'm not sure that I'm entirely happy with this distinction between already > compiled types and ones that have

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I'm not sure that I'm entirely happy with this distinction between already compiled types and ones that have not yet been compiled. It's a common Swift idiom to implement protocol requirements in extensions, which encourages a kind of modularity, if you will. Every so often (and maybe this isn't

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Friday, 29 April 2016, Matthew Johnson via swift-evolution > > wrote: > Does that mean the conformance declaration will be accepted by the compiler > under your proposal? I would really like to see this called out explicitly >

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

+1 Main part of proposal: Not sure that you need the required keyword, overload alone has proven sufficient in Java for the same feature. Related features: For calling default implementations in inherited protocols I think this is a valuable feature but should be a seperate thread. On Thursday,

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

It is a good idea to explicitly document the behaviour that this requirement for override is a compile time check only and does not mean that already compiled code has to be recompiled to allow a protocol to be retroactively fitted to an already compiled type. On Friday, 29 April 2016, Matthew

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Sent from my iPad > On Apr 28, 2016, at 5:49 PM, Erica Sadun wrote: > > >> On Apr 28, 2016, at 12:18 PM, Matthew Johnson wrote: >> We can't add the keywords if the structs are defined in a module we import >> but don't own. We are only

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 28, 2016, at 12:18 PM, Matthew Johnson wrote: > We can't add the keywords if the structs are defined in a module we import > but don't own. We are only declaring the conformance retroactively. The > ability to do this is a crucial aspect of generic

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Right, sorry, I should have clarified. The scenario to be supported here is that the code for structs A, B, and C cannot be modified. They could be part of the stdlib, for example, or a closed-source third-party library. On Thu, Apr 28, 2016 at 1:18 PM, Matthew Johnson

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Sent from my iPad > On Apr 28, 2016, at 1:09 PM, Erica Sadun via swift-evolution > wrote: > > Sorry, that's not my question, which doesn't involve protocols I don't own. > Let me restate. Given three types I don't own as follows: > > ``` > struct A : Frobnicate {

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I'm glad you brought this up and provided a clear example Xiaodi. Erica, as I mentioned a few days ago (and Dave A gave +1) this proposal cannot break retroactive modeling if it is going to fly. Can you please update it to clarify how you envision it interacts with retroactive modeling? Would

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Erica, In general I fully support this proposal. IMO Swift should be more explicit on what method in class/struct is required by protocol and if it overrides default implementation in protocol extension. Actually, personally I like the idea that we need even separate base class inheritance

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

On Thu, Apr 28, 2016 at 12:25 PM, Erica Sadun wrote: > > > > On Apr 28, 2016, at 11:05 AM, Xiaodi Wu wrote: > > > > How is retroactive modeling accommodated in this scheme? Say I want to > conform three types I don't own to a protocol of my design and

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> > On Apr 28, 2016, at 11:05 AM, Xiaodi Wu wrote: > > How is retroactive modeling accommodated in this scheme? Say I want to > conform three types I don't own to a protocol of my design and supply a > default implementation for a protocol requirement. How would I go

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

How is retroactive modeling accommodated in this scheme? Say I want to conform three types I don't own to a protocol of my design and supply a default implementation for a protocol requirement. How would I go about it? On Thu, Apr 28, 2016 at 11:53 Erica Sadun via swift-evolution <

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Draft. Criticism and suggestions both welcome. -- E Requiring Proactive Overrides for Default Protocol Implementations Proposal: tbd Author(s): Erica Sadun Status: tbd Review manager: tbd

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

func (protocolname1, protocolname2) commonmethod() -> Void { .. the >> implementation.. } >> >> - Tod Cunningham >> ________ >> From: swift-evolution-boun...@swift.org < >> swift-evolution-boun...@swift.org> on behalf of Josh

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

ift.org > <mailto:swift-evolution-boun...@swift.org>> on behalf of Josh Parmenter via > swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> > Sent: Wednesday, April 27, 2016 8:27 PM > To: Howard Lovatt > Cc: swift-evolution >

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 27, 2016, at 6:03 PM, Douglas Gregor wrote: >>> 2) Is “override” only required when there is a default implementation of >>> the protocol requirement, or is it required whenever you are implementing a >>> protocol requirement? >> >> Override is only because it is

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> > > Sent: Wednesday, April 27, 2016 8:27 PM > To: Howard Lovatt > Cc: swift-evolution > Subject: Re: [swift-evolution] [Pitch] Requiring proactive overrides for > default protocol implementations. > > On Apr 27, 2016, at 17:23, Howard Lovatt via swift-evolution < >

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

org <swift-evolution-boun...@swift.org> on behalf of Josh Parmenter via swift-evolution <swift-evolution@swift.org> Sent: Wednesday, April 27, 2016 8:27 PM To: Howard Lovatt Cc: swift-evolution Subject: Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

On Apr 27, 2016, at 17:23, Howard Lovatt via swift-evolution > wrote: I think that you should *always* have to write `override` when implementing a protocol method, you can think of this as override an abstract declaration. In

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I think that you should *always* have to write `override` when implementing a protocol method, you can think of this as override an abstract declaration. In particular I think the following should be enforced: protocol A { func a() } extension A { override func a() { ... } } struct

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 27, 2016, at 12:45 PM, L. Mihalkovic > wrote: > > Inline > > Regards > (From mobile) > > On Apr 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution > > wrote: > >> On Apr 27, 2016, at

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 27, 2016, at 12:31 PM, Erica Sadun wrote: > > On Apr 27, 2016, at 12:25 PM, Douglas Gregor > wrote: >> >> On Apr 27, 2016, at 10:10 AM, Erica Sadun > > wrote: >>>

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Sorry, I sent too early. Example should have been: struct Example: A { func get() -> T {...} } My mistake does bring up another question. What if it only conforms after the method is defined, in another module? extension Example: A {} On Thursday, 28 April 2016, Andrew Bennett

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Great proposal, I think it will clear up some mistakes. What happens when it is only an override sometimes? For example: protocol A { associatedtype Element func get() -> Element } extension A where Element: ArrayLiteralConvertible { func get() -> Element { return [] } } struct

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 27, 2016, at 9:56 PM, Erica Sadun wrote: > > >> On Apr 27, 2016, at 1:45 PM, L. Mihalkovic >> wrote: >> >> Inline >> >> Regards >> (From mobile) >> >>> On Apr 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

oun...@swift.org>> > on behalf of Erica Sadun via swift-evolution > <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> > Reply-To: Erica Sadun <er...@ericasadun.com<mailto:er...@ericasadun.com>> > Date: Wednesday, April 27, 2016 at 1:10 PM > T

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

on Wed Apr 27 2016, Matthew Johnson wrote: > Sent from my iPad > > On Apr 27, 2016, at 3:08 PM, Jérôme ALVES via swift-evolution > wrote: > > What if... > > FooBar.framework defines : > > public protocol A { > func foo() >

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

On Apr 27, 2016, at 2:08 PM, Jérôme ALVES wrote: > > What if... > > FooBar.framework defines : > public protocol A { > func foo() > } > public type B: A { > public func foo () { > … implementation … > } > } > > Other module defines : > import FooBar >

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

uglas Gregor <dgre...@apple.com<mailto:dgre...@apple.com>> Subject: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations. From the Swift Programming Language: Methods on a subclass that override the superclass’s implementation are marked

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

What if... FooBar.framework defines : public protocol A { func foo() } public type B: A { public func foo () { … implementation … } } Other module defines : import FooBar extension A { func foo() { .. default implementation … } } Jérôme > Le 27 avr. 2016 à 19:10,

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

IMO very important questions and suggestions. Firstly, wanted to ask about "required" keyword in your examples - do we expect to have it in meaning "implementing the protocol method" ? I'd like to have it very much. * About the "override" keyword : +1 from me. We should be clear and

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 27, 2016, at 10:10 AM, Erica Sadun wrote: > > From the Swift Programming Language: Methods on a subclass that override the > superclass’s implementation are marked with override—overriding a method by > accident, without override, is detected by the compiler as

[swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

>From the Swift Programming Language: Methods on a subclass that override the >superclass’s implementation are marked with override—overriding a method by >accident, without override, is detected by the compiler as an error. The >compiler also detects methods with override that don’t actually