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:
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 ;-) So, yes, support
the required 'default' in future version of Swift.
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
