This is an interesting idea. Here's another (I'm just spitballing here):
Extension methods without a requirement must be marked with a @nonrequired
attribute (names are all provisional).
If a requirement is later added to a protocol with the name of a previously
declared nonrequired method, an extension must also be declared marking those
method names @required:
protocol Foo { }
extension Foo {
@nonrequired func blah(x: Int) {
print(x + 100)
}
}
Later:
protocol FooChild : Foo {
func blah(x: Int)
}
// requires to compile
extension FooChild {
@required blah(x:)
}
The only point of this would be to allow it to be made clear to users whether
that protocol method is a requirement or not after extensions and retroactive
modeling have occurred, and thus help them reason about whether it would be
statically or dynamically dispatched.
Austin
Sent from my iPhone
> On May 22, 2016, at 12:53 PM, Matthew Johnson via swift-evolution
> <[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.
>
> 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.
>
>
>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
