> On May 22, 2016, at 9:53 PM, Matthew Johnson <[email protected]> wrote: > > >>> On May 22, 2016, at 12:36 PM, L. Mihalkovic <[email protected]> >>> wrote: >>> >>> >>> On May 22, 2016, at 5:31 PM, Matthew Johnson <[email protected]> wrote: >>> >>> >>> >>> Sent from my iPad >>> >>>>> On May 22, 2016, at 8:39 AM, L. Mihalkovic <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> On May 22, 2016, at 3:15 PM, Matthew Johnson <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Sent from my iPad >>>>> >>>>>>> On May 22, 2016, at 1:49 AM, Vladimir.S via swift-evolution >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> On 22.05.2016 3:01, L. Mihalkovic via swift-evolution wrote: >>>>>>> Read the proposal... I have an aversion to-go coffee cups that remind >>>>>>> people that hot coffee may burn them, and when my daughter was 4 we >>>>>>> explained to her why knives were to be handled with care, rather than >>>>>>> remove them all from her sight. IMHO the proposal evoques mandating >>>>>>> training wheels rather than letting people learn naturally from their >>>>>>> errors. >>>>>> >>>>>> I can partially support this opinion. But we have a situation with >>>>>> protocol extension methods and static dispatches in which we need >>>>>> Swift's help on compilation stage. IMO Using your words, right now we >>>>>> just got knife in our hands *without* any explanation. Then we hurt >>>>>> ourselves, and *then* we know that such methods will be dispatched >>>>>> statically(and the rule of dispatch is quite non-obvious). This is >>>>>> another extreme like "remove all knives". We need some golden middle. >>>>>> Personally I believe the solution is in compiler warning and in some >>>>>> method to 'fix' this warning. >>>>> >>>>> Why not just make it an error and require an annotation on the extension >>>>> methods? >>>> >>>> See >>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018560.html >>>> And >>>> https://github.com/lmihalkovic/swift-lang/tree/master/Dispatching.playground >>> >>> That doesn't answer my question. I don't like any of the suggestions you >>> posted. I think we should just leave the behavior as is (at least for now) >>> and just require annotations on non-default methods in protocol extensions >>> (making it an error to declare a non-default method without the annotation). >> >> Considering how things work fine the way they are today once THEIR logic is >> understood (the only problem today seems to be one of expectations mismatch, >> not that something is broken or illogic), it would IMHO be a waste of energy >> to revisit only to end up with a system that would only support a single >> model. It something is done, it might as well be to add freedom. >> >> So if you make it optional to have an attribute (I seem to recall chris >> explicitely saying that annotations were not the idiomatic swift way to >> convey these types of behavirial adjustments) on non required extension >> methods, then what you describe is basically one of the proposals I listed.. > > It would be pointless for this to be optional. The whole point is to have > the code reflect the fact that the dispatch semantics are likely to be > surprising until you learn the rules (and also if you forget to consider > them), and to always keep this fact in our minds as we work with protocol > extensions. > > Which of your proposals do you think this matches? > > 1. `override` in implementing classes. > 2. `straw_man_dynamic_dispatch` at call site. > 3. `straw_man_dynamic_dispatch` at declaration site in protocol extension. > 4. doesn’t make sense (we are never going to statically dispatch protocol > requirements and we can’t dynamically non-required extension methods in Swift > 3) > 5. `straw_man_default_attribute` on default methods in protocol extensions. > > None of these are what I suggest. What I suggest is that we leave behavior > alone and we *don’t* annotate default implementations because those don’t > surprise anyone. I suggest requiring this: > > `straw_man_static_dispatch` at declaration site of non-default methods in > protocol extensions. >
It truly was not obvious that this is a subset of what 3 is allowing? I debated adding something to the effect of "the attribute is NOT restricted to any particular type of method and can be applied to conformance providing method and/or additional-so-called helper methods", but thought it was self evident. Although it might be construed as surprising-on-first-encounter, it is statistically impossible that I would be the only person outside the core team who would find the current situation justifiable. I think the POP model is somewhat surprising when considered from a objc or even java viewpoint, but it does make sense when considered by itself, based on the explanations from last year's (or before) WWDC. > The only question is what actual modifier we use (`final` and `nondynamic` > are obvious candidates, but both are non-starters in my mind for reasons I > have stated earlier). > > I do think it would be a good idea to introduce this in Swift 3 as it is a > breaking change. > -1 for the lack of elegance. > >> for a simple reason mind you... what I listed is what I saw people debate. A >> few options were left out as being too complex to summarize, or not ringing >> true to what exists today and what has been explained about protocols with >> great clarity by Dave on stage at WWDC. Interestingly enough, the idea of >> default methods on the protocol itself (which I like in java8) was already >> listed by him and at least someone else in the compiler team. >> >> Coming from working in asm, c, c++, perl, tcl, vb, java, c#, js, objc, >> scala, typescript and go in that order, I can get used to anything as long >> as its logic seems reasonable and adequately explained. After reading so >> many emails I thought I might not be the only one craving a simple one page >> summary of what had been said so far. >> >> >>> >>>> >>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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
