As I explained on Twitter, the behavior is initially counterintuitive but in many ways the least surprising result.<br><br>(First, you are incorrect about P requiring a mutable property. That is not what var means in a protocol.)<br><br>However, you are right that two properties named value are being allowed. It seems strange at first but consider:<br><br>Given: a protocol P with only one requirement, but with a default implementation for that requirement. One would expect that any type T could retroactively conform to P. After all, either T has its own implementation of the requirement or it does not.<br><br>If the requirement is a property and not a method, and T has an identically named but not identically typed property, we allow this sort of "overloading" which is very much like overloading on the return type. This fulfills the expectation above that T can conform to P. Even requiring a warning in this scenario would break retroactive conformance.<br><br>The behavior at the call site is not harmful. A user of T may or may not see that it conforms to P. This is because conformance can be retroactive. Thus, when using an instance of T, references to the property are to T's own implementation. However, if the user can see P and the conformance T : P, they can always explicitly request P's differently typed implementation explicitly by using "as" (just like selecting an overloaded method with a different return type).<br><br>The behavior that is unexpected and potentially harmful is for the author of a type T trying to conform to P. It falls into the category of near-misses that includes unintentional typos in method names, etc. It is no more surprising than any of those cases where you, say, get the argument label spelled slightly wrong and end up without an intended override of a default implementation but two methods instead.<br><br>As mentioned earlier on this list, the user experience of writing a conforming type is suboptimal, and there are likely to be clever ways for the compiler or other tools to help. However, ripping out type inference or breaking retroactive conformance is not the way forward to solving this issue.<br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 12, 2017 at 05:15 Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12.04.2017 7:19, Jaden Geller wrote:<br class="gmail_msg">
><br class="gmail_msg">
>> On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution<br class="gmail_msg">
>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:<br class="gmail_msg">
>>> Hi all,<br class="gmail_msg">
>>><br class="gmail_msg">
>>> In a discussion about inferring parameter types from default value,<br class="gmail_msg">
>>> Slava brought up some performance problems caused by type inference for<br class="gmail_msg">
>>> stored properties in side types:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html</a><br class="gmail_msg">
>>><br class="gmail_msg">
>>> Towards the end, the post mentioned that some Swift team members<br class="gmail_msg">
>>> contemplated requiring types for stored properties in type declarations.<br class="gmail_msg">
>>> I think this idea deserves some more attention. Hence this last minute<br class="gmail_msg">
>>> idea-floating.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> In addition to solving a performance headache in implementation,<br class="gmail_msg">
>>> there're always the general benefit of making type declartion more<br class="gmail_msg">
>>> explicit and readable (clarity for reader should out-weigh pleasure of<br class="gmail_msg">
>>> the author). Making the language slightly more consistent (we are not<br class="gmail_msg">
>>> inferring types for default parameter values in function anyways).<br class="gmail_msg">
>>><br class="gmail_msg">
>>> The cons for doing this are obvious too: the inference makes the<br class="gmail_msg">
>>> language feels more friendly and is, undoubtedly, a beloved feature for<br class="gmail_msg">
>>> many. This would be a source breaking change.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Just thought I'd float the idea to gather some quick reaction. What do<br class="gmail_msg">
>>> y'all think?<br class="gmail_msg">
>><br class="gmail_msg">
>> Although it seems like only an implementation-side problem(i.e. "let's just improve<br class="gmail_msg">
>> implementation"), I see a benefits to require type for stored property *if* it is<br class="gmail_msg">
>> not obvious what the type is for *reader*. I.e. if we have something like this, I<br class="gmail_msg">
>> don't think we should require a type:<br class="gmail_msg">
>> struct S {<br class="gmail_msg">
>> var x = 0<br class="gmail_msg">
>> }<br class="gmail_msg">
><br class="gmail_msg">
> I think there is value in requiring a type annotation there. For example, this bug<br class="gmail_msg">
> would be avoided: <a href="https://twitter.com/benjaminencz/status/851892622213783552" rel="noreferrer" class="gmail_msg" target="_blank">https://twitter.com/benjaminencz/status/851892622213783552</a><br class="gmail_msg">
<br class="gmail_msg">
I believe the pointed problem is much wider, than type-inference and I even think<br class="gmail_msg">
this is bug(in design?) that should be fixed at least with warning.<br class="gmail_msg">
<br class="gmail_msg">
Please consider this example:<br class="gmail_msg">
<br class="gmail_msg">
protocol P {<br class="gmail_msg">
var value : Int32 {get}<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
extension P {<br class="gmail_msg">
var value : Int32 {return 20}<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
class C : P {<br class="gmail_msg">
let value = 4_000_000_000<br class="gmail_msg">
<br class="gmail_msg">
/// or even this:<br class="gmail_msg">
// let value : Int = 4_000_000_000<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
First, as class C conforms to P protocol, it must have *mutable* 'value' property<br class="gmail_msg">
Second, currently it seems like class C has two 'value' properties with different<br class="gmail_msg">
type. It is very strange(the principle of less surprise, yes?) and as we can see<br class="gmail_msg">
dangerous behavior. Was bug to <a href="http://bugs.swift.org" rel="noreferrer" class="gmail_msg" target="_blank">bugs.swift.org</a> submitted? If so, what was the reply of<br class="gmail_msg">
the core team?<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
>><br class="gmail_msg">
>> but I do think it will be better to require a type in such cases :<br class="gmail_msg">
>><br class="gmail_msg">
>> struct S{<br class="gmail_msg">
>> var x = something(SomeType(), 123, "123") // can be generic func<br class="gmail_msg">
>> }<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> Daniel Duan _______________________________________________<br class="gmail_msg">
>>> swift-evolution mailing <a href="mailto:listswift-evolution@swift.org" class="gmail_msg" target="_blank">listswift-evolution@swift.org</a><br class="gmail_msg">
>>> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>><br class="gmail_msg">
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
>>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-evolution mailing list<br class="gmail_msg">
>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>><br class="gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>