Sometimes I get the sense that the pleasure of discussing takes precedence over
the goal it serves, namely to create a language that will be the most
attractive it can be within a given complexity budget (meaning a balance
between the immediate reward of shiny new things and the long term evolvability
of the compiler). I seem to recall this item coming directly from chris as a
compiler cleanup task.
> On Jun 25, 2016, at 3:23 PM, Matthew Johnson via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Hi Austin,
>
> I’m sorry to say, but this proposal makes me really sad. I consider
> associated type inference one of the more elegant aspects of Swift. It would
> be very unfortunate to lose it.
>
> I am really pleased to see that Dmitri has offered an alternative that looks
> very reasonable. I’m hoping the Doug or Chris (or someone else from the core
> team) can chime in on the feasibility of this alternative. If it is
> considered viable and Dmitri isn’t able to write the proposal I would be
> happy to do so.
>
> If the alternative isn’t viable and we must proceed with a proposal to remove
> inference I think there is one crucial thing to consider that isn’t discussed
> in this proposal: retroactive modeling. As far as I can tell, this proposal
> will *prohibit* some types from conforming to some protocols. Specifically,
> if a type defines a typealias with a name that matches the name of an
> associatedtype in a protocol it would not be possible to retroactively model
> that protocol. Because of the name conflict an associatedtype declaration
> would not be allowed and the existing typealias would not meet the
> requirement. Consider this example:
>
> // Module A
> public struct S {
> public typealias Foo = Int
> }
>
> // Module B
> public protocol P {
> associatedtype Foo
> }
>
> // Module C
> import A
> import B
>
> // compiler error: `S` does not meet the `Foo` associatedtype requirement
> extension S : P {
> // compiler error: cannot define associatedtype `Foo` for `S` which
> already declares typealias `Foo`
> associatedtype Foo = String
> }
>
> I cannot support any proposal that breaks retroactive modeling in this way.
>
> Another item that is not mentioned in this proposal is that typealias is not
> the only way to meet an associatedtype requirement in the language today.
> For example, this code is legal:
>
> protocol Foo {
> associatedtype Bar
> }
> struct S : Foo {
> struct Bar {}
> }
>
> If we *must* drop inference I prefer the alternative of just doing that:
> dropping inference, but otherwise leaving things alone. All associated type
> requirements would need to be explicitly satisfied using one of the
> mechanisms that is currently valid for satisfying a non-inferred associated
> type requirement. The ability to satisfy these requirements in a variety of
> ways is a *benefit* that provides valuable flexibility.
>
> I agree that something should look for a good solution to the subclass
> typealias issue, but I don’t think this is it. Ideally we would find a
> solution that works well in the presence of retroactive modeling making code
> such as the following valid:
>
> // module A
> protocol P1 {
> associatedtype Foo
>
> @infers(Foo)
> var foo: Foo { get }
> }
> // module B
> protocol P2 {
> associatedtype Foo
>
> @infers(Foo)
> func bar() -> Foo
> }
>
> // module C
> class Base {
> let foo: String = "foo"
> }
> class Derived : Base {
> func bar() -> Int { return 42 }
> }
>
> // module D
> import A
> import B
> import C
> import D
> extension Base : P1 {}
> extension Derived : P2 {}
>
> We don’t always control the protocol or type definitions we want to make work
> together. The ability to make code that “should work together” actually do
> so with minimal fuss is one of the great things about Swift. Any time we
> interfere with retroactive modeling we increase the need for boilerplate
> adapter types, etc.
>
> One detail appears to be implied by the proposal but isn’t explicitly stated.
> Specifically, it looks like the intent is that other than only being valid
> when used to meet a protocol requirement, associatedtype otherwise works like
> a typealias. It would be good to have this behavior clarified if the
> proposal moves forward.
>
> -Matthew
>
>
>
>> On Jun 25, 2016, at 12:50 AM, Austin Zheng via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> Hello all,
>>
>> Per Chris Lattner's list of open Swift 3 design topics
>> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put
>> together a proposal for removing type inference for associated types.
>>
>> It can be found here:
>> https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/XXXX-remove-assoctype-inference.md
>>
>> Thoughts, criticism, and feedback welcome. There are at least two slightly
>> different designs in the proposal, and I'm sure people will have ideas for
>> even more.
>>
>> Best,
>> Austin
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
