Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

> On May 3, 2017, at 2:09 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution >> > wrote: >> >> I definitely agree that it's a feature that

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

I should add, the reason final is inapt in this situation is at least twofold. The first is, of course, that this makes it impossible to guarantee source compatibility and offer additional functionality in a protocol extension, since any such addition would break unknowable amounts of existing

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

Well, the revised integer protocols that were just approved do just that: some functions are defaults and others cannot be overridden. Smart shifts, for example, are deliberately not customization points. This is also the case for Equatable: you get to define ==, but != is not a protocol

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

@Brent, What aspects of the current proposal do you have reservations about? -- Howard. On 3 May 2017 at 18:09, Brent Royal-Gordon wrote: > On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I definitely agree that

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution > wrote: > > I definitely agree that it's a feature that _can_ be used unwisely, but the > fact remains that it _is_ used pervasively in the standard library, and > deliberately I'm not so sure that's

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

You raise three points: 1. The harm is the inconsistent behaviour of extensions for both structs and classes, as outlined in the first section of the proposal. This is confusing for beginners and difficult to debug in large code bases, particularly those involving third party libraries were

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

I'm sorry, it's been a while. What is the harm that you are trying to cure, and how does this design accomplish that task? What you call "unexpected" is intentional. Many protocols, including the revised integer protocols that were just approved, distinguish between protocol requirements for

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

I haven't replied to these messages for a while since it has taken some time to formulate a proposal that incorporates the feedback give - thanks for the feedback. The new proposal allows retroactively added protocols to be exported and ad-hoc code reuse, the two areas of concern. Comments?

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

+1 Extensions are a great feature and I’m really glad that Swift has them. Conflicts should be handled by improving import and disambiguation features like Xiaodi says which is useful for other cases as well. -Thorsten > Am 18.04.2017 um 03:47 schrieb Xiaodi Wu via swift-evolution >

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

Neat. Seems like that'd be a bug. On Wed, Apr 19, 2017 at 9:40 PM, Howard Lovatt wrote: > As it stands at the moment splitting to multiple files doesn't work. EG: > > ModuleA > > A.swift > > public protocol P { > > func m() -> String > > } > > extension Int: P { > >

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

As it stands at the moment splitting to multiple files doesn't work. EG: ModuleA A.swift public protocol P { func m() -> String } extension Int: P { public func m() -> String { return "AP.m" } } ModuleB B.swift public protocol P { func m() -> String } extension Int: P { public func

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

Simple: you put the user code that needs the more accurate library in one file and import only the more accurate library there, and you put the user code that needs the more performant library in a separate file and import only the more performant library there! Swift's devotion to file-based

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

Comments in-line below -- Howard. On 17 Apr 2017, at 9:01 am, Xiaodi Wu wrote: This continues to forbid use cases that are critical. I think "critical" is overstating the importance. Plenty of successful languages do not have extensions. Extensions have been discussed

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

This continues to forbid use cases that are critical. For instance, I am writing a library that vends additional conformances for Float and Double. Any numerics library would need to do the same. Your design would eliminate all such libraries, which is a non-starter. I am not sure what defects

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

@Brent, I have updated the proposal to address your concerns, in particular I don't see that retrospectively adding methods and protocols has been removed it has just had its ugly corners rounded. See revised proposal below particularly the end of section "Retrospectively adding protocols and

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

> On Apr 13, 2017, at 3:10 PM, Howard Lovatt via swift-evolution > wrote: > > I don't see that retroactive conformance needs to be exportable. If it is > exported then you cannot prevent clashes from two modules, this is a known > problem in C#. Because of this and

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

I don't see that retroactive conformance needs to be exportable. If it is exported then you cannot prevent clashes from two modules, this is a known problem in C#. Because of this and other problems with C# extensions, this style of extension were rejected by other language communities (notably

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

The retroactive conformance needs to be exportable. If one cannot vend a library that conforms standard library types to new protocols, then that is a non-starter. On Thu, Apr 13, 2017 at 06:07 Howard Lovatt wrote: > @Xiaodi, > > You can safely post-hoc add protocols

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

@Xiaodi, You can safely post-hoc add protocols and methods provided that they are final, do not override, and are not exported from the module. See version 2 of the proposal below. -- Howard. # Proposal: Split extension usage up into implementing methods and adding methods and protocols

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

Thanks for the explanation Adrian, I also had to Google this :) Personally I'd love some kind of solution that would prevent this confusion of why this method does different things when called on the same object in two different ways, but I don't have any ideas how this could be solved... It's

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

I myself pitched that requirement quite a few times on the list. Thank you, finally I understood why it’s not possible. Now I fully agree that the requirement of an override should not exist for the base type conforming to the protocol. For those who might misunderstand the concept of

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

On 11.04.2017 1:51, Xiaodi Wu via swift-evolution wrote: > On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution > > wrote: > > In response to Jordan Rose's comment I suggest the following change: > > Proposal:

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

As far as I'm aware, eliminating retroactive conformances is a non-starter. On Mon, Apr 10, 2017 at 21:44 Howard Lovatt wrote: > @Xiaodi, > > You make two drugs. > > 1. Deliberately making retroactive conformance outside of the file in > which the type is declared

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

@Xiaodi, You make two drugs. 1. Deliberately making retroactive conformance outside of the file in which the type is declared illegal because of the problems it causes. See all the questions on Swift Users and watch people learning Swift get caught out. 2. Outside of the file in which the

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > In response to Jordan Rose's comment I suggest the following change: > > Proposal: Split extension usage up into implementing methods and adding > static functions > > > Currently extension

[swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

In response to Jordan Rose's comment I suggest the following change: Proposal: Split extension usage up into implementing methods and adding static functions Currently extension methods are confusing because they have different dispatch rules for the same syntax. EG: protocol P {