> On Aug 22, 2016, at 11:32 PM, Xiaodi Wu <[email protected]> wrote:
>
> On Mon, Aug 22, 2016 at 11:59 PM, Jonathan Hull via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
> Hi everyone,
>
> We talked about this before when we were discussing mixins, and there seemed
> to be generally positive feelings towards it as a feature for the future.
>
> It's been some time now since the original discussion, so perhaps you could
> refresh our collective memory (or at least, mine): although it *seems* like
> this feature might be useful, I can't recall a concrete use case where I've
> felt like I needed this feature--do you have some examples?
Ideally, the biggest use is that it helps to (partially) solve the diamond
problem (and similar issues) by forcing/allowing disambiguation when there are
multiple protocols being conformed to. This will become more of an issue if we
allow protocols or extensions to add storage. Your proposed syntax actually
does a better job of it than mine because mine was always shown as attached to
some sort of implementation, whereas yours could potentially allow access to a
default implementation under a new name.
Other than that, it generally allows us to bypass/mitigate conflicts between
protocols. In the current version, you are unable to conform to both protocols
(either because it won’t compile or because you can’t satisfy the semantics of
both protocols) without designing the protocols together to avoid conflicts.
(I have definitely had to go back and rename/refactor properties on a protocol
for this reason… which I couldn’t have done if I didn’t control both protocols).
Take a look at Eiffel’s ‘rename’ & ’select’ features for similar functionality
and use-cases.
Ultimately, this is a step in the direction of having true mixins.
> I am fairly certain this affects the ABI though, so I thought I would
> bring it up now.
>
> If two protocols have methods/properties with the same name, but different
> signatures, we need a way to distinguish between them when attempting to
> conform to both.
>
> protocol A {
> var x:Int {get set}
> }
>
> protocol B {
> var x:Double {get set}
> }
>
> Methods can be overloaded that differ in arguments or return type, so it
> seems like this problem mainly exists with *properties* that differ in
> type--am I wrong?
There is also the case of functions with the same name and signature, but
different semantics. There may be no single implementation which
simultaneously satisfies the semantics for both protocols. By renaming one of
the functions, we are able to provide separate implementations for each
requirement (which allows both protocols to function as intended).
There may also be functions in different protocols with different names but the
same semantics and signature. This will allow a single implementation to
satisfy both protocols without duplication.
Finally, we may want to rename an inherited default implementation to avoid
conflicting with another protocol's default implementation in cases where we
don’t want to override it.
> One possibility is to allow a struct/class/enum to conform to the protocol
> while renaming one (or both) of the clashing methods:
>
> struct C: A,B {
> var x:Int
> var y:Double implements B.x
> }
>
> The conforming method/property would still have to have the same signature,
> but could have a different name (and parameter labels). It would also allow
> protocol methods which have identical signatures and semantics, but different
> names to be implemented using the same method (i.e ‘implements D.z & E.w’).
>
> When something is cast to the protocol (say ‘as B’), then calling the
> property (e.g. ‘x’) would end up calling the implementation of the renamed
> property ( ‘y’ in this example) on the conforming type.
>
> Reflecting on this proposed change, it occurs to me that something of value
> would be lost, and I think that this something is actually rather valuable:
>
> Today, when I see that a type conforms to (for example) Sequence, I know that
> certain methods and/or properties exist on that type. Protocol conformance
> guarantees a certain API, not just certain semantics.
It isn’t actually lost, however. When working with it as a Sequence (for
example), that API would be intact using the original names. It is only when
working with it as its own type that the renaming would have an effect.
> Perhaps one way to mitigate this loss would be to have any renamed members
> listed *in the declaration of conformance*, something like this (with some
> additional bikeshedding):
>
> ```
> struct MyGreatType : Sequence (count => length) {
> // MyGreatType conforms to Sequence but renames `count` to `length`
> }
> ```
Yes, putting it in the conformance declaration is a definite possibility we
should consider.
>
> I think we would also want a way to retroactively conform using existing
> properties/methods in an extension declaring conformance. Not sure what the
> best syntax for that would be. Off the top of my head (though I would love
> to have something with less cruft):
>
> extension D:B {
> @conform(to: B.x, with: D.y)
> }
>
> or maybe just:
>
> extension D:B {
> D.y implements B.x
> }
>
> If renamed members are declared along with protocol conformance, then the
> syntax for retroactive modeling follows naturally:
>
> ```
> extension D : B (x => y) { }
> // again, the actual notation here is ugly
> // but the underlying idea, I think, is worth considering
> ```
Yup
One thing I like about this is that it helps to solve the diamond problem. ‘x’
could be a default implementation in B which D does not override. I think this
is an important case which my original proposal didn’t address fully.
We should keep bikeshedding the syntax though...
Thanks,
Jon
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
