> 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: >>> >>> 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. > >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
