> On Jun 28, 2016, at 11:36 PM, Paulo Faria <pa...@zewo.io> wrote:
> 
>> 
>> On Jun 29, 2016, at 2:54 AM, Douglas Gregor <dgre...@apple.com 
>> <mailto:dgre...@apple.com>> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Jun 28, 2016, at 10:51 PM, Paulo Faria <pa...@zewo.io 
>> <mailto:pa...@zewo.io>> wrote:
>> 
>>> 
>>>> On Jun 29, 2016, at 2:48 AM, Austin Zheng <austinzh...@gmail.com 
>>>> <mailto:austinzh...@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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to