[swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

[Xiaodi Wu]

Yes, examples will be helpful.


On Fri, Jun 23, 2017 at 19:28 David Moore via swift-evolution <
swift-evolution at swift.org> wrote:

> I do indeed have quite a few real examples of this, such prompted me to
> bring this up. I think this could be done without any impact to existing
> code, but it would require some type of keyword. Take the following as a
> possible prototype.
>
> protocol Foo {
>     associatedtype T
> }
>
> struct Bar<T> : Foo {
>     keyword typealias T // Or really any other syntactical implementation.
> }
>
> With an opt-in method we could implement this without affecting existing
> code, thereby making this more viable. I will send some examples later.
>
> On Jun 23, 2017, at 6:52 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> There could be source-breaking implications for such a feature, especially
> with retroactive conformance. Therefore, I think this could be very tricky
> and I'd want to be convinced that the benefits are very great to risk such
> a disturbance. Here, I think the problem is rather mild, and here's why:
>
> It is true that, in your example specifically, renaming T to U is the only
> solution (that I know of, anyway). However, for any "serious" protocol P,
> there's likely to be a required property of type P.T, or a function that
> takes an argument of type P.T or returns a value of type P.T. Therefore,
> implementing that requirement in Bar with a corresponding
> property/argument/return value of type Bar.T would generally do the trick.
>
> Have you got any real-world examples where you're running into this issue?
>
> On Fri, Jun 23, 2017 at 17:03 David Moore via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Hello Swift Evolution,
>>
>> This may have already been discussed before, but I just came across a
>> bothersome language aspect which reminded me to propose a solution.
>> Currently, if we want to add generics to a protocol the only way to do so
>> is with associated types. I am quite fine with the current approach with
>> respect to those semantics.
>>
>> There is, however, a weakness that is built in with using associated
>> types. That weakness is the lack of associated type and generic inference.
>> To be more clear about what I mean, take the following as an example.
>>
>> protocol Foo {
>>     associatedtype T
>> }
>>
>> The foregoing protocol is quite basic, but uses an associated type with
>> the name “T.” Giving the associated type that name will illustrate the
>> dilemma encountered later on down the pipeline.
>>
>> struct Bar<T> : Foo {
>>     // What am I supposed to do? The name is used for both the generic
>> and the type alias Foo needs for conformance.
>>     typealias T = T // Error!
>> }
>>
>> The above illustrates a situation where we want to connect the generic,
>> which is supposedly named appropriately, and the protocol’s associated
>> type. There is no elegant solution for this at the moment. All I could do
>> is the following.
>>
>> struct Bar<U> : Foo {
>>     typealias T = U // Not nearly as readable.
>> }
>>
>> Now, there may be a few ways to go about adding support for generic
>> inference. The compiler as it is already does some awesome inference get
>> when it comes to generics, so why not take it a step further? I propose the
>> introduction of a keyword, or anything else that could work, to specify
>> explicitly what a given type alias declaration would do when it comes to
>> inferencing. Requiring a keyword would ensure source compatibility remains
>> intact, and it would also make the code more readable.
>>
>> I don’t know if this would be something that people could find useful,
>> but I surely would. The implicit mapping of an associated type and a given
>> generic by their names, would be a natural development.
>>
>> Let me know if this is just useless, or if could be a potential feature.
>>
>> Thank you,
>> David Moore
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170624/bc6fb3b7/attachment.html>