> On 24 Jun 2017, at 08:50, David Sweeris via swift-evolution
> <[email protected]> wrote:
>
>
>> On Jun 23, 2017, at 5:28 PM, David Moore via swift-evolution
>> <[email protected]> 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.
>
> At one point there was talk of just having generic parameters automatically
> becoming typealiases:
> struct Bar<T> : Foo {
> // `T` is automatically an implicit typealias for, well, `T`
> }
>
> Dunno if that’s still the plan (or to what degree it ever was), but it’d work
> for me. I don’t even think it’d break source compatibility (though it may
> make a lot of typealiases unneeded.
>
> - Dave Sweeris
Automatic implicit type aliases sounds the ideal solution, at least from the
point of view of the programmer.
If that is too difficult or costly to the compiler, I don't think adding
another keyword would be a good solution or compromise. Maybe it can be also be
solved by supporting some way of referring to Bar.T and Foo.T explicitly:
struct Bar<T> : Foo {
typealias T = Bar.T
}
Or:
struct Bar<T> : Foo {
typealias Foo.T = Bar.T
}
Or:
struct Bar<T> : Foo {
typealias Foo.T = T
}
The compiler could help by suggesting fix-it if encountered with the original
non-compiling code.
--
Víctor Pimentel
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
