On Fri, Jun 16, 2017 at 14:42 Paul Cantrell <[email protected]> wrote:
> On Jun 16, 2017, at 2:26 PM, Xiaodi Wu <[email protected]> wrote: > > On Fri, Jun 16, 2017 at 14:06 Paul Cantrell via swift-evolution < > [email protected]> wrote: > >> On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution < >> [email protected]> wrote: >> >> On Jun 16, 2017, at 8:44 AM, David Hart <[email protected]> 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`. >> > > 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. > > >> P >> >> >> >> >> On 16 Jun 2017, at 16:33, Erica Sadun <[email protected]> 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 <[email protected]> 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 < >> [email protected]> wrote: >> >> >> On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution < >> [email protected]> wrote: >> >> >> on Wed Jun 14 2017, Chris Lattner <[email protected]> wrote: >> >> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
