> 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] <mailto:[email protected]>> wrote: >> On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> On Jun 16, 2017, at 8:44 AM, David Hart <[email protected] >>> <mailto:[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. So it’s really a question of what the tolerance for breakage is among the core team. > > > P > > >> >>> >>>> On 16 Jun 2017, at 16:33, Erica Sadun <[email protected] >>>> <mailto:[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] >>>>> <mailto:[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] <mailto:[email protected]>> wrote: >>>>>> >>>>>> >>>>>>> On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution >>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> >>>>>>> on Wed Jun 14 2017, Chris Lattner <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>>>> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>>>>>>>> <[email protected] <mailto:[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> >>>>>>>>> <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 >>>>>> <https://github.com/apple/swift-evolution/pull/724> >>>>>> >>>>>> -- E >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
