>Possible solution: if you want a new protocol adoption to map to some existing
>method or property then you must explicitly write that. You can't just adopt
>the protocol in an empty extension.
>
> extension Int: BoundedType {
> static var min = Int.min
> static var max = Int.max
> }
>
>but with some other syntax that isn't ambiguous. Code completion and compiler
>fix-its could suggest this when the class already implements something
>suitable.
That would be really neat. On my wishlist though would be something
along the same lines going in the forward direction, where there's
some sort of distinction between a class or struct overriding a
dynamically dispatched default implementation for a method declared in
a protocol and a method that doesn't override anything but happens to
'shadow' or 'mask' a statically dispatched method in a protocol
extension that's never fully overridden. I guess the objection here is
that a change in syntax for that scenario would make new protocol
adoptions after the fact difficult; but there must be a way to have it
both ways...
On Wed, Jan 6, 2016 at 3:48 AM, Greg Parker <[email protected]> wrote:
>
>> On Jan 5, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution
>> <[email protected]> wrote:
>>
>>> Taking inspiration from syntax used for methods in classes that override
>>> methods in superclasses, require methods that override dynamically
>>> dispatched default implementations in protocol extensions to use the
>>> override keyword. Likewise, forbid the override keyword if the method being
>>> implemented instead 'masks' (would that be the right word?) a statically
>>> dispatched method in a protocol extension which can nonetheless be invoked
>>> by upcasting to the protocol.
>>
>> This has been suggested before, usually in the form of a separate
>> `implement` keyword. The main problem is that it makes it impossible to
>> write a protocol after the fact which formalizes some existing pattern in
>> the types.
>>
>> What do I mean by that? Well, imagine you need generic access to the `min`
>> and `max` static properties of the various integer types. There's no
>> existing protocol that includes those members. But you can write one and
>> then extend the integer types to conform to your new protocol:
>>
>> protocol BoundedIntegerType: IntegerType {
>> static var min: Self { get }
>> static var max: Self { get }
>> }
>> extension Int: BoundedType {}
>> extension Int8: BoundedType {}
>> extension Int16: BoundedType {}
>> extension Int32: BoundedType {}
>> extension Int64: BoundedType {}
>>
>> func printLowestPossibleValueOfValue<Integer: BoundedIntegerType>(x:
>> Integer) {
>> print(Integer.min)
>> }
>>
>> This only works because `min` and `max` *don't* need any special marking to
>> be used to satisfy a requirement. Requiring a keyword like you suggest would
>> remove that feature.
>
> Possible solution: if you want a new protocol adoption to map to some
> existing method or property then you must explicitly write that. You can't
> just adopt the protocol in an empty extension.
>
> extension Int: BoundedType {
> static var min = Int.min
> static var max = Int.max
> }
>
> but with some other syntax that isn't ambiguous. Code completion and compiler
> fix-its could suggest this when the class already implements something
> suitable.
>
>
> --
> Greg Parker [email protected] Runtime Wrangler
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
