[swift-evolution] [Pitch] Remove type inference for associated types

[Douglas Gregor]

> On Jun 28, 2016, at 11:36 PM, Paulo Faria <paulo at zewo.io> wrote:
> 
>> 
>> On Jun 29, 2016, at 2:54 AM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Jun 28, 2016, at 10:51 PM, Paulo Faria <paulo at zewo.io <mailto:paulo at zewo.io>> wrote:
>> 
>>> 
>>>> On Jun 29, 2016, at 2:48 AM, Austin Zheng <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> wrote:
>>>> 
>>>> If you tested it, there's a problem with the current behavior independent of associated type inference, and it should be fixed whether or not the proposal is accepted.
>>> 
>>> I don’t think it should be an error. Normally we can have any number of functions with the same name but different return types. By failing in this specific case would be like saying that when you implement a protocol with an associated type you can only return what’s defined in the associated type. I don’t think that should be the behaviour we expect.
>> 
>> This seems very related to the near-miss checking I mentioned in my other reply to Austin. 
>> 
>>   - Doug
>> 
> 
> Actually, the more I think about it I get the conclusion that It really shouldn’t be an error. Otherwise this would mean that you wouldn’t be able to use the default implementation and have a function with the same name but returning another type. And if we can’t get an error; We’re just making it easier for the bugs by forcing one to keep the typealias and his own implementation in sync. With inference this wouldn’t exist. This is a really hard one. Looks like the decision is already made. If this is really the case; All I can say is that I really hope this comes back in Swift 4. 

For reference, my implementation makes it a warning, not an error, and you can suppress the warning by moving the similar-but-not-selected declaration to a different extension.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/ac58dfa1/attachment.html>