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.
I like that this is minimal impact because it is optional. Since it is
optional, I wonder if making it visually distinct from the mandatory
keywords such as "override" for classes would be optimal, perhaps by making
these @annotations.
Otherwise the naming is near perfect, IMO. It follows by analogy with
`override` and `convenience`. There is one nit here that `override func`
reads well in two senses: it's an overriding function with a certain
signature _and_ it's overriding a function with that signature. Moreover,
"override" can be read as a noun (a nouned verb, but plausibly a noun
nonetheless), fitting in better with "convenience" and "default." By
contrast, an `extend func` would be an extending function _but_ it's not
extending a function, so it may read more awkwardly. It's also definitely
not a noun. Might it be possible simply to reuse the keyword `extension` in
this context?
As to the overall design, I like this much better than all previous
alternatives, which are amply discussed in your proposal text.
···
On Wed, Jun 14, 2017 at 12:11 PM, 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.
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: it would mimic how override works with only one keyword, it would not introduce a completely new keyword, and it would provide progressive disclosure (your usually start implementing types before going deeper in default implementations). Yes, it would generate warnings at all current default implementations, but it wouldn’t break source compatibility and would provide a lot of value for developers.
Perhaps a future version of Swift could transform that warning into an error to provide the most value and really mirror the override behavior.
···
On 14 Jun 2017, at 19:11, 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.
+1 on the idea of this. The same sort of thing is extremely valuable classes that are trying to implement "optional requirements” in @objc protocols.
-Chris
···
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.
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.
it would mimic how override works with only one keyword, it would not
···
On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote:
introduce a completely new keyword, and it would provide progressive
disclosure (your usually start implementing types before going deeper in
default implementations). Yes, it would generate warnings at all current
default implementations, but it wouldn’t break source compatibility and
would provide a lot of value for developers.
Perhaps a future version of Swift could transform that warning into an
error to provide the most value and really mirror the override behavior.
On 14 Jun 2017, at 19:11, 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.
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.
...I may need to take this back; the design has annotations on the default
and not on the overriding functions, which means there should be no
negative impact on retroactive conformance (unless I'm mistaken). In that
case, it might not need to be optional, and then reducing two keywords to
one might be a nice idea...
it would mimic how override works with only one keyword, it would not
···
On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:
introduce a completely new keyword, and it would provide progressive
disclosure (your usually start implementing types before going deeper in
default implementations). Yes, it would generate warnings at all current
default implementations, but it wouldn’t break source compatibility and
would provide a lot of value for developers.
Perhaps a future version of Swift could transform that warning into an
error to provide the most value and really mirror the override behavior.
On 14 Jun 2017, at 19:11, 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.
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.
...I may need to take this back; the design has annotations on the default and not on the overriding functions, which means there should be no negative impact on retroactive conformance (unless I'm mistaken). In that case, it might not need to be optional, and then reducing two keywords to one might be a nice idea…
Making them optional is critical for source stability. I think David’s suggestion is a better overall design but I’m not sure it will fly. It would require a migrator to add `default` to all default implementations in protocol extensions in existing code. The window for changes like that may have already passed.
···
On Jun 14, 2017, at 1:12 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> 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:
it would mimic how override works with only one keyword, it would not introduce a completely new keyword, and it would provide progressive disclosure (your usually start implementing types before going deeper in default implementations). Yes, it would generate warnings at all current default implementations, but it wouldn’t break source compatibility and would provide a lot of value for developers.
Perhaps a future version of Swift could transform that warning into an error to provide the most value and really mirror the override behavior.
On 14 Jun 2017, at 19:11, 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.
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.
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.
I would support this if the core team is willing to take on the code churn it will cause.
···
On Jun 14, 2017, at 1:23 PM, Haravikk via swift-evolution <swift-evolution@swift.org> 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:
I like this proposal a lot and also like Xiaodi’s suggestion that these be made into @ attributes.
···
On Jun 14, 2017, at 1:48 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
I like that this is minimal impact because it is optional. Since it is optional, I wonder if making it visually distinct from the mandatory keywords such as "override" for classes would be optimal, perhaps by making these @annotations.
Otherwise the naming is near perfect, IMO. It follows by analogy with `override` and `convenience`. There is one nit here that `override func` reads well in two senses: it's an overriding function with a certain signature _and_ it's overriding a function with that signature. Moreover, "override" can be read as a noun (a nouned verb, but plausibly a noun nonetheless), fitting in better with "convenience" and "default." By contrast, an `extend func` would be an extending function _but_ it's not extending a function, so it may read more awkwardly. It's also definitely not a noun. Might it be possible simply to reuse the keyword `extension` in this context?
As to the overall design, I like this much better than all previous alternatives, which are amply discussed in your proposal text.
On Wed, Jun 14, 2017 at 12:11 PM, 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.
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.
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.
···
On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution <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:
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.
I like the idea of fixing this area of the language and I’m happy to see others already pointed out that extend could be implicit and does not need to be introduced at all, where default would become necessary for protocol default implementations.
If I’m not mistaken this _can_ be an improvement now, which later could be syntactically sugared by default implementations in protocols (which would not require the default keyword):
···
--
Adrian Zubarev
Sent with Airmail
Am 14. Juni 2017 um 20:46:50, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:
On Jun 14, 2017, at 1:23 PM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution <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.
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.
I would support this if the core team is willing to take on the code churn it will cause.
This would be great and very easily to fix in migrations, definitely dissipating the gray area where protocol extensions now live.
···
El 14 jun 2017, a las 20:01, David Hart via swift-evolution <swift-evolution@swift.org> escribiĂł:
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: it would mimic how override works with only one keyword, it would not introduce a completely new keyword, and it would provide progressive disclosure (your usually start implementing types before going deeper in default implementations). Yes, it would generate warnings at all current default implementations, but it wouldn’t break source compatibility and would provide a lot of value for developers.
ditto. IMO it also makes the protocol extension much more expressive
and easy to read.
···
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.
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.
···
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.
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.
...I may need to take this back; the design has annotations on the default and not on the overriding functions, which means there should be no negative impact on retroactive conformance (unless I'm mistaken). In that case, it might not need to be optional, and then reducing two keywords to one might be a nice idea…
Making them optional is critical for source stability. I think David’s suggestion is a better overall design but I’m not sure it will fly. It would require a migrator to add `default` to all default implementations in protocol extensions in existing code. The window for changes like that may have already passed.
The Swift 4 compiler in -swift-version 3 modes generates extra warnings: as long as it compiles, it is still source-compatible.
···
On 14 Jun 2017, at 20:19, Matthew Johnson <matthew@anandabits.com> wrote:
On Jun 14, 2017, at 1:12 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> 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:
it would mimic how override works with only one keyword, it would not introduce a completely new keyword, and it would provide progressive disclosure (your usually start implementing types before going deeper in default implementations). Yes, it would generate warnings at all current default implementations, but it wouldn’t break source compatibility and would provide a lot of value for developers.
Perhaps a future version of Swift could transform that warning into an error to provide the most value and really mirror the override behavior.
On 14 Jun 2017, at 19:11, 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.
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.
Yes, I think we are all in vigorous agreement about this. The question is
whether, at this point in Swift's evolution, a wide-ranging migration due
to a new required keyword will be well tolerated. If not, then the solution
is constrained.
···
On Wed, Jun 14, 2017 at 3:37 PM, 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.
I agree with omitting the extend keyword, as it does not really add anything useful to the language. The default keyword, on the other hand, seems as if it will be really useful for extending protocols. It would be useful for a handful of cases, and it further introduces safety to Swift as a whole.
···
On Jun 14, 2017, 3:56 PM -0400, VĂctor Pimentel via swift-evolution <swift-evolution@swift.org>, wrote:
> El 14 jun 2017, a las 20:01, David Hart via swift-evolution <swift-evolution@swift.org> escribiĂł:
>
> 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: it would mimic how override works with only one keyword, it would not introduce a completely new keyword, and it would provide progressive disclosure (your usually start implementing types before going deeper in default implementations). Yes, it would generate warnings at all current default implementations, but it wouldn’t break source compatibility and would provide a lot of value for developers.
+1 to adding only the "default" keyword.
This would be great and very easily to fix in migrations, definitely dissipating the gray area where protocol extensions now live.
Sure, it’s not out of the question, technically. The question is whether a
migration of such scale is desirable, which is a difficult judgment call.
···
On Wed, Jun 14, 2017 at 16:43 David Hart <david@hartbit.com> wrote:
On 14 Jun 2017, at 20:19, Matthew Johnson <matthew@anandabits.com> wrote:
On Jun 14, 2017, at 1:12 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution < >> 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.
...I may need to take this back; the design has annotations on the default
and not on the overriding functions, which means there should be no
negative impact on retroactive conformance (unless I'm mistaken). In that
case, it might not need to be optional, and then reducing two keywords to
one might be a nice idea…
Making them optional is critical for source stability. I think David’s
suggestion is a better overall design but I’m not sure it will fly. It
would require a migrator to add `default` to all default implementations in
protocol extensions in existing code. The window for changes like that may
have already passed.
The Swift 4 compiler in -swift-version 3 modes generates extra warnings:
as long as it compiles, it is still source-compatible.
it would mimic how override works with only one keyword, it would not
introduce a completely new keyword, and it would provide progressive
disclosure (your usually start implementing types before going deeper in
default implementations). Yes, it would generate warnings at all current
default implementations, but it wouldn’t break source compatibility and
would provide a lot of value for developers.
Perhaps a future version of Swift could transform that warning into an
error to provide the most value and really mirror the override behavior.
On 14 Jun 2017, at 19:11, 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.
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.
Yes, I think we are all in vigorous agreement about this. The question is whether, at this point in Swift's evolution, a wide-ranging migration due to a new required keyword will be well tolerated. If not, then the solution is constrained.
I personally vote to accept such a migration at this point, but I am not sure how others feel.
···
Sent from my iPhone
On 14 Jun 2017, at 21:41, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Wed, Jun 14, 2017 at 3:37 PM, 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.
I personally don't want to waste time in migrations if the resulting code is worse, but I think this proposal is very reasonable. It's an improvement and the migration is painless if the fixit applies.
And it's a feature that if you were using it, you definitely know what's going on.
Also, if this proposal were accepted as is, having to opt-in, I would personally not want it.
···
On 14 Jun 2017, at 23:22, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:
Yes, I think we are all in vigorous agreement about this. The question is whether, at this point in Swift's evolution, a wide-ranging migration due to a new required keyword will be well tolerated. If not, then the solution is constrained.
I personally vote to accept such a migration at this point, but I am not sure how others feel.