The example you presented – whilst utilizing a potential syntactical expression – seems like a step in the right direction. Specifically, I like the addition of a keyword as it introduces a more explicit invocation of the behavior.
Moreover, it does seem only natural to allow the re-mapping to occur for most (if not all) definitions between a protocol and the conforming type. I also agree that this feature would be a more advanced one, which does not need to be exposed for cases where this is not needed. I would also propose a slight adjustment to the syntax, albeit in a rugged form, to add the type annotation to the right hand side as well. E.g. remapped var P.f = S.g. If the above were to be respected, then the overall functionality of this could be expanded greatly, but it’d have to be seen how it would affect the implementation. To clarify, if we added the type annotation to the right side too, we may theoretically be able to change the type from the enclosing type to some arbitrary type and its conforming requirement. Now, if this seems a bit too polymorphic the compiler could just emit an error which restricts the type annotation to the enclosing type. Best, David Moore On Jul 5, 2017, 1:53 PM -0400, Chris Lattner <[email protected]>, wrote: > > > On Jun 27, 2017, at 2:26 PM, David Moore via swift-evolution > > <[email protected]> wrote: > > > > > > Onto Option #2, the idea of using base types to express more explicit > > definitions to solve the initial problem. When it comes to using a base > > type to correctly disambiguate these types of situations, it may be > > familiar to some who like a more concrete implementation, although it > > eliminates possible convenience, but still requires knowledge. Options #2 > > would look something like the following. > > > > protocol Foo { > > associatedtype ABC > > } > > > > struct Bar<ABC>: Foo { > > typealias Foo.ABC = Bar.ABC // Quite explicit and communicates the > > solution clearly. > > } > > > > Options #2, as you can see above, would also be source compatible because > > it would not impose on already defined typealias’ or other implementations. > > This could be an opt-in feature. However, I don’t know if it is as nice as > > just pure inference, which doesn’t seem too much more difficult than this > > would be, but I’m not sure about that. > > > > Something like this seems like the right approach to me. Swift’s underlying > implementation model (for non-@objc protocols) does not require exact name > matches and uniqueness. This means that (from an implementation perspective) > it would be possible to allow “remapping” of requirements to implementations, > even if they have different (or conflicting) names. > > This can be useful in some cases, like the one you give above. That said, it > would be a power user feature only necessary in specific situations, and thus > it makes sense to have super explicit syntax. Given that remapping can apply > to any requirement (be it a type, method, property, subscript, …) it may make > sense to make it an explicit decl modifier like: > > protocol P { > var x : Int > func f() -> Int > } > > struct S : P { > var y : Int > remapped var P.x = y > > func g() -> Int { return 42 } > remapped var P.f = g > } > > or something. > > -Chris >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
