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. > 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
