Introducing role keywords to reduce hard-to-find bugs

   Sorry, initially sent off-list:

   I think this proposal is a great idea. But I would vote for the alternative of
   only having default and implicitly deducing extend when default is not specified:

This wouldn't work with the fundamental design decision that these are optional keywords, which IMO is absolutely key.

Hmm, I'm inclined to agree with David that only the default keyword really seems like it's necessary, and that extend can be implied.

I'm not so sure. If they are optional, then it depends on developer if he/she wants to explicitly mark some func to avoid possible errors. Please look here :

1. First we have this

protocol A {
func foo() {}
}

and we write extension (possible in another file)

extension A {
extent func bar() {} // I'm sure currently I want *additional* 'bar' method
}

2. Then 'A' protocol has been changed for some reason :

protocol A {
func foo() {}
func bar() {}
}

Now, if we have 'extent' - we(compiler) can detect the problem here('bar' was not the default implementation for A's requirement). Without 'extent' - 'bar' will be default implementation without our intent for this.

So, in case suggested keywords are both optional - IMO we need both.
In case 'default' is required - then yes, we need only it.

I think a good plan would be to make default required in a later Swift version (Swift 5) for example, and only warn for now. If I remember correctly, the Core Team has redefined source-stability as the ability for the compiler to continue to compile a previous version of Swift without new errors, but gives us a little bit of wiggle room to introduce some new errors in new versions of Swift (see Swift 4 for example).

I see two ways:

Either we acknowledge that this proposal is important for the future of Swift and we are ready to impose a future version of Swift making default required,
Or if its not, we need to keep both keywords and they need to stay optional. In that case, I would personally reconsider the usefulness of the proposal: it would introduce a feature that is not easily discoverable, introduces a new keyword, and is more complex than it ought to be.

Of course, my opinion is that it’s definitely worth the breakage in a future version of Swift.

David.

···

On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
On 14.06.2017 21:23, Haravikk via swift-evolution wrote:

On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

My preference would be to just add the default keyword, and have breaches treated as warnings using the current behaviour, which we can eliminate and elevate to an error in future once people have had a chance to change their code.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I too really like this proposal; personally I can attest to how it probably would have saved some time and headache with the Foundation overlay as well as swift-corelibs-foundation (specifically when adopting Collection and friends for types)

Would it be reasonable to have this apply to typealiases as well? Or does not only make sense for functions/properties etc?

I presume this would also be something exposed in the interfaces when viewing APIs?

Does this perhaps have any objc protocol interaction? (e.g. do we need an attribute to adopt things? Or perhaps can we leverage this to address the disparity 'tween objc protocols and swift protocols for optional methods via this same mechanism?)

···

On Jun 14, 2017, at 10:46 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Pull request: https://github.com/apple/swift-evolution/pull/724

-- E

···

On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

I like only having “default,” and I like David’s plan for achieving that.

• • •

It seems that this proposal could help mitigate the problems described in the classic “Ghost of Swift Bugs Future” (https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future). There’s a nice new convention (I think?) of:

`extend` / no modifier in extension → static dispatch
`default` in extension → dynamic dispatch

(Does this always hold in an extensions?)

Knowing whether the extension’s author •intended• static or dynamic dispatch could also allow the compiler to give better warnings: about shadowing at declaration sites, and also also potentially at call sites where multiple extension methods could match depending on the compile-time type of the receiver.

Might it be worth describing some of these warnings out in the proposal? I realize warnings don’t require full swift-evo treatment, but it would be nice to at least sketch out in the “Impact on Existing Code” section what the warnings might look like.

Cheers,

Paul

···

On Jun 14, 2017, at 4:51 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 14.06.2017 21:23, Haravikk via swift-evolution wrote:

On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

   Sorry, initially sent off-list:

   I think this proposal is a great idea. But I would vote for the alternative of
   only having default and implicitly deducing extend when default is not specified:

This wouldn't work with the fundamental design decision that these are optional keywords, which IMO is absolutely key.

Hmm, I'm inclined to agree with David that only the default keyword really seems like it's necessary, and that extend can be implied.

I think a good plan would be to make default required in a later Swift version (Swift 5) for example, and only warn for now.

   Sorry, initially sent off-list:

   I think this proposal is a great idea. But I would vote for the alternative of
   only having default and implicitly deducing extend when default is not specified:

This wouldn't work with the fundamental design decision that these are optional keywords, which IMO is absolutely key.

Hmm, I'm inclined to agree with David that only the default keyword really seems like it's necessary, and that extend can be implied.

I'm not so sure. If they are optional, then it depends on developer if he/she wants to explicitly mark some func to avoid possible errors. Please look here :

1. First we have this

protocol A {
func foo() {}
}

and we write extension (possible in another file)

extension A {
extent func bar() {} // I'm sure currently I want *additional* 'bar' method
}

2. Then 'A' protocol has been changed for some reason :

protocol A {
func foo() {}
func bar() {}
}

Now, if we have 'extent' - we(compiler) can detect the problem here('bar' was not the default implementation for A's requirement). Without 'extent' - 'bar' will be default implementation without our intent for this.

So, in case suggested keywords are both optional - IMO we need both.
In case 'default' is required - then yes, we need only it.

I think a good plan would be to make default required in a later Swift version (Swift 5) for example, and only warn for now. If I remember correctly, the Core Team has redefined source-stability as the ability for the compiler to continue to compile a previous version of Swift without new errors, but gives us a little bit of wiggle room to introduce some new errors in new versions of Swift (see Swift 4 for example).

I see two ways:

  * Either we acknowledge that this proposal is important for the future of Swift and
    we are ready to impose a future version of Swift making default required,
  * Or if its not, we need to keep both keywords and they need to stay optional. In
    that case, I would personally reconsider the usefulness of the proposal: it would
    introduce a feature that is not easily discoverable, introduces a new keyword,
    and is more complex than it ought to be.

Of course, my opinion is that it’s definitely worth the breakage in a future version of Swift.

For me it's worth the breakage even in current version of Swift :wink: So, yes, support the required 'default' in future version of Swift.

···

On 15.06.2017 0:51, David Hart wrote:

On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution <swift-evolution@swift.org >> <mailto:swift-evolution@swift.org>> wrote:
On 14.06.2017 21:23, Haravikk via swift-evolution wrote:

On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> <mailto:swift-evolution@swift.org>> wrote:
On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> <mailto:swift-evolution@swift.org>> wrote:

David.

My preference would be to just add the default keyword, and have breaches treated as warnings using the current behaviour, which we can eliminate and elevate to an error in future once people have had a chance to change their code.
_______________________________________________
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

   Sorry, initially sent off-list:

   I think this proposal is a great idea. But I would vote for the alternative of
   only having default and implicitly deducing extend when default is not specified:

This wouldn't work with the fundamental design decision that these are optional keywords, which IMO is absolutely key.

Hmm, I'm inclined to agree with David that only the default keyword really seems like it's necessary, and that extend can be implied.

I think a good plan would be to make default required in a later Swift version (Swift 5) for example, and only warn for now.

I like only having “default,” and I like David’s plan for achieving that.

• • •

It seems that this proposal could help mitigate the problems described in the classic “Ghost of Swift Bugs Future” (https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future). There’s a nice new convention (I think?) of:

`extend` / no modifier in extension → static dispatch
`default` in extension → dynamic dispatch

(Does this always hold in an extensions?)

Knowing whether the extension’s author •intended• static or dynamic dispatch could also allow the compiler to give better warnings: about shadowing at declaration sites, and also also potentially at call sites where multiple extension methods could match depending on the compile-time type of the receiver.

+10000

To me static dispatch is an optimisation over dynamic one, but it should only be applied when it cannot introduce side effects or when the programmer is asking for it explicitly: code path execution should never change no matter how we are casting a reference (base type or subclass) and users should know if they are implementing a method that will never be called as it shadows a default method only declared in a protocol extension.

Thanks for reminding the list of this article: https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future

These problems should be addressed.

···

Sent from my iPhone

On 15 Jun 2017, at 05:41, Paul Cantrell via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 4:51 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
On 14.06.2017 21:23, Haravikk via swift-evolution wrote:

On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Might it be worth describing some of these warnings out in the proposal? I realize warnings don’t require full swift-evo treatment, but it would be nice to at least sketch out in the “Impact on Existing Code” section what the warnings might look like.

Cheers,

Paul

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Erica, any thoughts on only having default and making it an error in a future version of Swift like was discussed on this thread? The idea seems to have a few supporters.

···

On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

Pull request: https://github.com/apple/swift-evolution/pull/724

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

As we say in our introduction, we're pitching the most conservative approach.

The proposal was designed for minimal language impact. It chooses a conservative approach that can be phased in first over time and language release over more succinct alternatives that would impact existing code bases.

We discuss the one keyword version (which most of us are a fan of) in the alternatives. The core team has to decide how much they're willing to allow existing code to warn and/or break, which is the consequence of the one keyword solution.

-- E

···

On Jun 16, 2017, at 7:44 AM, David Hart <davidhart@fastmail.com> wrote:

Erica, any thoughts on only having default and making it an error in a future version of Swift like was discussed on this thread? The idea seems to have a few supporters.

On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

Pull request: https://github.com/apple/swift-evolution/pull/724

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Okay, I undertand. I’m just worried that the proposal is a net negative if the keywords stay optional. I’ll mention it in more detail once we get to the review period.

Thanks for the work on the proposal!!

···

On 16 Jun 2017, at 16:33, Erica Sadun <erica@ericasadun.com> wrote:

As we say in our introduction, we're pitching the most conservative approach.

The proposal was designed for minimal language impact. It chooses a conservative approach that can be phased in first over time and language release over more succinct alternatives that would impact existing code bases.

We discuss the one keyword version (which most of us are a fan of) in the alternatives. The core team has to decide how much they're willing to allow existing code to warn and/or break, which is the consequence of the one keyword solution.

-- E

On Jun 16, 2017, at 7:44 AM, David Hart <davidhart@fastmail.com <mailto:davidhart@fastmail.com>> wrote:

Erica, any thoughts on only having default and making it an error in a future version of Swift like was discussed on this thread? The idea seems to have a few supporters.

On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

Pull request: https://github.com/apple/swift-evolution/pull/724

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Okay, I undertand. I’m just worried that the proposal is a net negative if the keywords stay optional. I’ll mention it in more detail once we get to the review period.

Thanks for the work on the proposal!!

I believe a breaking change has little chance of being accepted at this point in the language lifecycle. Adding opt-in compiler auditing to increase safety is, IMO, a net positive. It's a deliberate trade-off. We have included other designs to allow the core team to choose an alternative they feel is best for the philosophy and direction of Swift. This doesn't close the door to future language releases enhancing the concept, phasing out the second keyword, or introducing keywords for additional safety auditing.

I find it a dangerous philosophy to insist that any new proposal be ideologically pure. Imperfect proposals can still improve the language within the realities of the timelines, user base, and code base of the Swift community.

-- E

···

On Jun 16, 2017, at 8:44 AM, David Hart <davidhart@fastmail.com> wrote:

On 16 Jun 2017, at 16:33, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

As we say in our introduction, we're pitching the most conservative approach.

The proposal was designed for minimal language impact. It chooses a conservative approach that can be phased in first over time and language release over more succinct alternatives that would impact existing code bases.

We discuss the one keyword version (which most of us are a fan of) in the alternatives. The core team has to decide how much they're willing to allow existing code to warn and/or break, which is the consequence of the one keyword solution.

-- E

On Jun 16, 2017, at 7:44 AM, David Hart <davidhart@fastmail.com <mailto:davidhart@fastmail.com>> wrote:

Erica, any thoughts on only having default and making it an error in a future version of Swift like was discussed on this thread? The idea seems to have a few supporters.

On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

Pull request: https://github.com/apple/swift-evolution/pull/724

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

1 Like

Okay, I undertand. I’m just worried that the proposal is a net negative if the keywords stay optional. I’ll mention it in more detail once we get to the review period.

Thanks for the work on the proposal!!

I believe a breaking change has little chance of being accepted at this point in the language lifecycle. Adding opt-in compiler auditing to increase safety is, IMO, a net positive. It's a deliberate trade-off. We have included other designs to allow the core team to choose an alternative they feel is best for the philosophy and direction of Swift. This doesn't close the door to future language releases enhancing the concept, phasing out the second keyword, or introducing keywords for additional safety auditing.

I find it a dangerous philosophy to insist that any new proposal be ideologically pure. Imperfect proposals can still improve the language within the realities of the timelines, user base, and code base of the Swift community.

-- E

I share David’s concern. I also tend to think Erica’s correct about breaking changes. If the core team says “go ahead and break it,” then I’m all for it, but that seems unlikely.

FWIW, if we’re sticking with the two-keyword approach, the language could emit warnings for _any_ extension members that aren’t marked with either `extend` or `default`.

P

···

On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 16, 2017, at 8:44 AM, David Hart <davidhart@fastmail.com <mailto:davidhart@fastmail.com>> wrote:

On 16 Jun 2017, at 16:33, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

As we say in our introduction, we're pitching the most conservative approach.

The proposal was designed for minimal language impact. It chooses a conservative approach that can be phased in first over time and language release over more succinct alternatives that would impact existing code bases.

We discuss the one keyword version (which most of us are a fan of) in the alternatives. The core team has to decide how much they're willing to allow existing code to warn and/or break, which is the consequence of the one keyword solution.

-- E

On Jun 16, 2017, at 7:44 AM, David Hart <davidhart@fastmail.com <mailto:davidhart@fastmail.com>> wrote:

Erica, any thoughts on only having default and making it an error in a future version of Swift like was discussed on this thread? The idea seems to have a few supporters.

On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

Pull request: https://github.com/apple/swift-evolution/pull/724

-- E

_______________________________________________
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

Okay, I undertand. I’m just worried that the proposal is a net negative if
the keywords stay optional. I’ll mention it in more detail once we get to
the review period.

Thanks for the work on the proposal!!

I believe a breaking change has little chance of being accepted at this
point in the language lifecycle. Adding opt-in compiler auditing to
increase safety is, IMO, a net positive. It's a deliberate trade-off. We
have included other designs to allow the core team to choose an alternative
they feel is best for the philosophy and direction of Swift. This doesn't
close the door to future language releases enhancing the concept, phasing
out the second keyword, or introducing keywords for additional safety
auditing.

I find it a dangerous philosophy to insist that any new proposal be
ideologically pure. Imperfect proposals can still improve the language
within the realities of the timelines, user base, and code base of the
Swift community.

-- E

I share David’s concern. I also tend to think Erica’s correct about
breaking changes. If the core team says “go ahead and break it,” then I’m
all for it, but that seems unlikely.

FWIW, if we’re sticking with the two-keyword approach, the language could
emit warnings for _any_ extension members that aren’t marked with either
`extend` or `default`.

If the language were to do that, then it would certainly be superior to use
the one-keyword approach, since this is equal breakage with an extra
keyword.

···

On Fri, Jun 16, 2017 at 14:06 Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote:

On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
On Jun 16, 2017, at 8:44 AM, David Hart <davidhart@fastmail.com> wrote:

P

On 16 Jun 2017, at 16:33, Erica Sadun <erica@ericasadun.com> wrote:

As we say in our introduction, we're pitching the most conservative
approach.

The proposal was designed for minimal language impact. It chooses a
conservative approach that can be phased in first over time and language
release over more succinct alternatives that would impact existing code
bases.

We discuss the one keyword version (which most of us are a fan of) in the
alternatives. The core team has to decide how much they're willing to allow
existing code to warn and/or break, which is the consequence of the one
keyword solution.

-- E

On Jun 16, 2017, at 7:44 AM, David Hart <davidhart@fastmail.com> wrote:

Erica, any thoughts on only having default and making it an error in a
future version of Swift like was discussed on this thread? The idea seems
to have a few supporters.

On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

Pull request: https://github.com/apple/swift-evolution/pull/724

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

The described problem might be one of the most famous itches of the language, but imho the bar for new keywords* should be higher than that — and there are alternatives:

First, I guess many would like to see this to be valid Swift:

protocol Foo {
  func bar() {
    print("Default implementation called")
  }
}

It's the most convenient way of avoiding typos: avoid to type :wink:
Imho this might already be enough, but for a full alternative for "default", I'd suggest something like this:

extension Foo {
  func Foo.bar() {
    print("String has its own implementation")
  }
}

(to make it more familiar for those with a C++ background, "Foo::bar" could be used instead :wink:

Additional benefit: This wouldn't be limited to protocols — and it could possibly help in weird situations when two protocols declare functions with identical signature...

extension String: Foo {
  func Foo.bar() {
    print("String has its own implementation")
  }

  func Foo.barr() {
    // compiler error, Foo defines no function "barr"
  }

  func barr() {
    // this is fine, no connection to a protocol
  }
}

- Tino

* well, I guess "default" is not really a new keyword… but you get the point

1 Like

I’d support the breaking change here to allow the language to evolve properly instead of introducing halve baked opt-ins and workarounds for issues that totally deserve a fix. The first thought that I had when reading the proposal the first time was, that extend does not add any benefit to the language and should be implicit by default, where on the other hand default solves a real problem we’re having today. David was quicker and pitched the ideal solution by making default necessary in Swift 4 which is a breaking change but it solves the issue nicely.

That said, personally I would not support the opt-in version.

···

--
Adrian Zubarev
Sent with Airmail

Am 16. Juni 2017 um 21:06:58, Paul Cantrell via swift-evolution (swift-evolution@swift.org) schrieb:

On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 16, 2017, at 8:44 AM, David Hart <davidhart@fastmail.com> wrote:

Okay, I undertand. I’m just worried that the proposal is a net negative if the keywords stay optional. I’ll mention it in more detail once we get to the review period.

Thanks for the work on the proposal!!

I believe a breaking change has little chance of being accepted at this point in the language lifecycle. Adding opt-in compiler auditing to increase safety is, IMO, a net positive. It's a deliberate trade-off. We have included other designs to allow the core team to choose an alternative they feel is best for the philosophy and direction of Swift. This doesn't close the door to future language releases enhancing the concept, phasing out the second keyword, or introducing keywords for additional safety auditing.

I find it a dangerous philosophy to insist that any new proposal be ideologically pure. Imperfect proposals can still improve the language within the realities of the timelines, user base, and code base of the Swift community.

-- E

I share David’s concern. I also tend to think Erica’s correct about breaking changes. If the core team says “go ahead and break it,” then I’m all for it, but that seems unlikely.

FWIW, if we’re sticking with the two-keyword approach, the language could emit warnings for _any_ extension members that aren’t marked with either `extend` or `default`.

P

On 16 Jun 2017, at 16:33, Erica Sadun <erica@ericasadun.com> wrote:

As we say in our introduction, we're pitching the most conservative approach.

The proposal was designed for minimal language impact. It chooses a conservative approach that can be phased in first over time and language release over more succinct alternatives that would impact existing code bases.

We discuss the one keyword version (which most of us are a fan of) in the alternatives. The core team has to decide how much they're willing to allow existing code to warn and/or break, which is the consequence of the one keyword solution.

-- E

On Jun 16, 2017, at 7:44 AM, David Hart <davidhart@fastmail.com> wrote:

Erica, any thoughts on only having default and making it an error in a future version of Swift like was discussed on this thread? The idea seems to have a few supporters.

On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

Pull request: https://github.com/apple/swift-evolution/pull/724

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I think there's a lot of people who want this. I'd have to do a search through the archives but hasn't it been said that this isn't likely to happen soon?

-- E

···

On Jun 16, 2017, at 12:21 PM, Tino Heth <2th@gmx.de> wrote:

The described problem might be one of the most famous itches of the language, but imho the bar for new keywords* should be higher than that — and there are alternatives:

First, I guess many would like to see this to be valid Swift:

protocol Foo {
  func bar() {
    print("Default implementation called")
  }
}

Okay, I undertand. I’m just worried that the proposal is a net negative if the keywords stay optional. I’ll mention it in more detail once we get to the review period.

Thanks for the work on the proposal!!

I believe a breaking change has little chance of being accepted at this point in the language lifecycle. Adding opt-in compiler auditing to increase safety is, IMO, a net positive. It's a deliberate trade-off. We have included other designs to allow the core team to choose an alternative they feel is best for the philosophy and direction of Swift. This doesn't close the door to future language releases enhancing the concept, phasing out the second keyword, or introducing keywords for additional safety auditing.

I find it a dangerous philosophy to insist that any new proposal be ideologically pure. Imperfect proposals can still improve the language within the realities of the timelines, user base, and code base of the Swift community.

-- E

I share David’s concern. I also tend to think Erica’s correct about breaking changes. If the core team says “go ahead and break it,” then I’m all for it, but that seems unlikely.

FWIW, if we’re sticking with the two-keyword approach, the language could emit warnings for _any_ extension members that aren’t marked with either `extend` or `default`.

If the language were to do that, then it would certainly be superior to use the one-keyword approach, since this is equal breakage with an extra keyword.

I wouldn’t consider new warnings to be “breakage.” Warnings offer a gentler migration path than non-compilation.

Unfortunately, the single keyword approach wouldn’t support warnings the same way. So it’s really a question of what the tolerance for breakage is among the core team.

···

On Jun 16, 2017, at 2:26 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Fri, Jun 16, 2017 at 14:06 Paul Cantrell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 16, 2017, at 8:44 AM, David Hart <davidhart@fastmail.com <mailto:davidhart@fastmail.com>> wrote:

P

On 16 Jun 2017, at 16:33, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

As we say in our introduction, we're pitching the most conservative approach.

The proposal was designed for minimal language impact. It chooses a conservative approach that can be phased in first over time and language release over more succinct alternatives that would impact existing code bases.

We discuss the one keyword version (which most of us are a fan of) in the alternatives. The core team has to decide how much they're willing to allow existing code to warn and/or break, which is the consequence of the one keyword solution.

-- E

On Jun 16, 2017, at 7:44 AM, David Hart <davidhart@fastmail.com <mailto:davidhart@fastmail.com>> wrote:

Erica, any thoughts on only having default and making it an error in a future version of Swift like was discussed on this thread? The idea seems to have a few supporters.

On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

Pull request: https://github.com/apple/swift-evolution/pull/724

-- E

_______________________________________________
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

Okay, I undertand. I’m just worried that the proposal is a net negative
if the keywords stay optional. I’ll mention it in more detail once we get
to the review period.

Thanks for the work on the proposal!!

I believe a breaking change has little chance of being accepted at this
point in the language lifecycle. Adding opt-in compiler auditing to
increase safety is, IMO, a net positive. It's a deliberate trade-off. We
have included other designs to allow the core team to choose an alternative
they feel is best for the philosophy and direction of Swift. This doesn't
close the door to future language releases enhancing the concept, phasing
out the second keyword, or introducing keywords for additional safety
auditing.

I find it a dangerous philosophy to insist that any new proposal be
ideologically pure. Imperfect proposals can still improve the language
within the realities of the timelines, user base, and code base of the
Swift community.

-- E

I share David’s concern. I also tend to think Erica’s correct about
breaking changes. If the core team says “go ahead and break it,” then I’m
all for it, but that seems unlikely.

FWIW, if we’re sticking with the two-keyword approach, the language could
emit warnings for _any_ extension members that aren’t marked with either
`extend` or `default`.

If the language were to do that, then it would certainly be superior to
use the one-keyword approach, since this is equal breakage with an extra
keyword.

I wouldn’t consider new warnings to be “breakage.” Warnings offer a
gentler migration path than non-compilation.

Unfortunately, the single keyword approach wouldn’t support warnings the
same way.

No, but even that could offer benefits, and if transitional it would phase
in the benefits while phasing in the change.

So it’s really a question of what the tolerance for breakage is among the

core team.

Indeed.

···

On Fri, Jun 16, 2017 at 14:42 Paul Cantrell <cantrell@pobox.com> wrote:

On Jun 16, 2017, at 2:26 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Fri, Jun 16, 2017 at 14:06 Paul Cantrell via swift-evolution < > swift-evolution@swift.org> wrote:

On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution < >> swift-evolution@swift.org> wrote:
On Jun 16, 2017, at 8:44 AM, David Hart <davidhart@fastmail.com> wrote:

P

On 16 Jun 2017, at 16:33, Erica Sadun <erica@ericasadun.com> wrote:

As we say in our introduction, we're pitching the most conservative
approach.

The proposal was designed for minimal language impact. It chooses a
conservative approach that can be phased in first over time and language
release over more succinct alternatives that would impact existing code
bases.

We discuss the one keyword version (which most of us are a fan of) in the
alternatives. The core team has to decide how much they're willing to allow
existing code to warn and/or break, which is the consequence of the one
keyword solution.

-- E

On Jun 16, 2017, at 7:44 AM, David Hart <davidhart@fastmail.com> wrote:

Erica, any thoughts on only having default and making it an error in a
future version of Swift like was discussed on this thread? The idea seems
to have a few supporters.

On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution < >> swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote:

on Wed Jun 14 2017, Chris Lattner <swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote:

Some pals and I have been kicking an idea around about introducing
better ways to support the compiler in protocol extensions. We want

to eliminate some hard-to-detect bugs. We've been brainstorming on
how to do this without affecting backward compatibility and
introducing a minimal impact on keywords.

We'd love to know what you think of our idea, which is to introduce
"role" keywords. Roles allow the compiler to automatically check the
intended use of a extension member definition against its protocol
declarations, and emit errors, warnings, and fixits as needed. We
think it's a pretty straightforward approach that, if adopted,
eliminates an entire category of bugs.

The draft proposal is here:
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
<https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>

Thanks in advance for your thoughtful feedback,

+1 on the idea of this.

ditto. IMO it also makes the protocol extension much more expressive
and easy to read.

--
-Dave

Pull request: https://github.com/apple/swift-evolution/pull/724

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I’ve already mentioned this in this thread. This is one of the missing features from the generics manifesto, however it’s (almost) a syntactic sugar only. It means that if we would enforce default in Swift 4, then having default implementation directly inside protocols would be really a syntactic and additional change only, which is a good sign. :wink:

···

--
Adrian Zubarev
Sent with Airmail

Am 16. Juni 2017 um 20:39:21, Tino Heth via swift-evolution (swift-evolution@swift.org) schrieb:

The described problem might be one of the most famous itches of the language, but imho the bar for new keywords* should be higher than that — and there are alternatives:

First, I guess many would like to see this to be valid Swift:

protocol Foo {
func bar() {
print("Default implementation called")
}
}

It's the most convenient way of avoiding typos: avoid to type :wink:
Imho this might already be enough, but for a full alternative for "default", I'd suggest something like this:

extension Foo {
func Foo.bar() {
print("String has its own implementation")
}
}

(to make it more familiar for those with a C++ background, "Foo::bar" could be used instead :wink:

Additional benefit: This wouldn't be limited to protocols — and it could possibly help in weird situations when two protocols declare functions with identical signature...

extension String: Foo {
func Foo.bar() {
print("String has its own implementation")
}

func Foo.barr() {
// compiler error, Foo defines no function "barr"
}

func barr() {
// this is fine, no connection to a protocol
}
}

- Tino

* well, I guess "default" is not really a new keyword… but you get the point
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

1 Like

The described problem might be one of the most famous itches of the language, but imho the bar for new keywords* should be higher than that — and there are alternatives:

First, I guess many would like to see this to be valid Swift:

protocol Foo {
  func bar() {
    print("Default implementation called")
  }
}

It's the most convenient way of avoiding typos: avoid to type :wink:

Absolutely. This is the more natural way to describe most default implementations; it’s more concise and eliminates the possibility of errors for the common case.

Imho this might already be enough, but for a full alternative for "default", I'd suggest something like this:

extension Foo {
  func Foo.bar() {
    print("String has its own implementation")
  }
}

On top of your first syntax, this would be useful when the extension is further constrained, e.g.,

extension Foo where Self: Comparable {
  func Foo.bar() {
    print(“I use Comparable for my Foo”)
  }
}

(to make it more familiar for those with a C++ background, "Foo::bar" could be used instead :wink:

Joking aside, “Foo::bar” has one advantage if it’s applied universally: it’s unambiguous if we allow it in method references. For example, we could say

  someString.Foo::bar()

to mean “call the function that String used to satisfy the requirement Foo.bar()”. If instead it were

  someString.Foo.Foo.bar()

it looks like we’re referring to a member named “Foo” within String, and a “bar” inside that. One would end up having to write the example differently, e.g.,

  (someString as Foo).bar()

C# has set some precedent for using “.” when declaring the function, though, and there are obvious advantages to not introducing a new sigil like “::” into Swift because it brings complexity and the potential for confusion with “.”.

Additional benefit: This wouldn't be limited to protocols — and it could possibly help in weird situations when two protocols declare functions with identical signature...

extension String: Foo {
  func Foo.bar() {
    print("String has its own implementation")
  }

  func Foo.barr() {
    // compiler error, Foo defines no function "barr"
  }

  func barr() {
    // this is fine, no connection to a protocol
  }
}

Absolutely.

Thanks for writing this up, Tino; I was going to send a very similar response :slight_smile:

  - Doug

···

On Jun 16, 2017, at 11:21 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

3 Likes

I wrote about how the problem this addresses has affected us at Tumblr:

http://developear.com/blog/2017/02/26/swift-protocols.html

TL/DR:

This is a massive problem in large Swift codebases

3 Likes
Terms of Service

Privacy Policy

Cookie Policy