<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">Hi Dave,</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Like you said, you approach does not solve the bug.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:13px">And this is the bug: If your protocol `Foo` has a function `foo(X)`, and your type has a function `foo(Y)` <i>where Y can be turned into X through the use of default parameters</i>, then it’s impossible for your type to conform to `Foo`, even though you could use it as a `Foo` in your code. In practice, I think this only matters if you’re using “macros” like <span style="color:rgb(187,44,162)">__LINE__</span> or something as your default parameter, but it’s still annoying (to me, anyway).</div><div><br></div></blockquote><div><br></div><div class="gmail_default" style="font-family:georgia,serif">as this proposal does.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">I still think if we can call instance.function(), we should also call (instance as protocol).function(). If we can't, there must be something not right here.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">zhaoxin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 17, 2016 at 3:32 AM, Dave via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Instead of adding stuff to the protocol declaration, can we add it to the object definition?</div><div><br></div><div>Right now, IMHO, there’s a bug in the way protocols and functions w/ default parameters interact (or rather, don’t)…</div><div><br></div><div>Say I have this protocol (which, BTW, I end up adding to a lot of my projects for providing default values):</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="color:#bb2ca2">protocol</span> Initable {</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> <span style="color:#bb2ca2">init</span>()</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">}</div></div><div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)">// Along with most other builtin types I use</div></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(187,44,162)">extension<span style="color:#000000"> </span><span style="color:#703daa">Int</span><span style="color:#000000"> : </span><span style="color:#4f8187">Initable</span><span style="color:#000000"> {}</span></div></div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><br></div></div></blockquote><div>and this class:</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><div style="margin:0px;line-height:normal"><span style="color:#bb2ca2">class</span> Variable <T: Initable> {</div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">var</span> value: <span style="color:#703daa">T</span></div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">let</span> name: <span style="color:#703daa">String</span></div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">init</span>(path: <span style="color:#703daa">String</span> = <span style="color:#bb2ca2">__FILE__</span>, line: <span style="color:#703daa">Int</span> = <span style="color:#bb2ca2">__LINE__</span>) {</div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">self</span>.<span style="color:#4f8187">value</span> = T()</div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">self</span>.<span style="color:#4f8187">name</span> = <span style="color:#31595d">getDeclNameFromSource</span>(path: path, line: line)</div><div style="margin:0px;line-height:normal"> }</div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">init</span>(<span style="color:#bb2ca2">_</span> value: <span style="color:#703daa">T</span>, path: <span style="color:#703daa">String</span> = <span style="color:#bb2ca2">__FILE__</span>, line: <span style="color:#703daa">Int</span> = <span style="color:#bb2ca2">__LINE__</span>) {</div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">self</span>.<span style="color:#4f8187">value</span> = value</div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">self</span>.<span style="color:#4f8187">name</span> = <span style="color:#31595d">getDeclNameFromSource</span>(path: path, line: line)</div><div style="margin:0px;line-height:normal"> }</div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">init</span>(name: <span style="color:#703daa">String</span>, value: <span style="color:#703daa">T</span>) {</div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">self</span>.<span style="color:#4f8187">value</span> = value</div><div style="margin:0px;line-height:normal"> <span style="color:#bb2ca2">self</span>.<span style="color:#4f8187">name</span> = name</div><div style="margin:0px;line-height:normal"> }</div><div style="margin:0px;line-height:normal">}</div><div><br></div></div></blockquote><div>Now, `Initable` says* that</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><span style="color:#bb2ca2">var</span><span style="color:#000000"> x = </span><span style="color:#703daa">T</span><span style="color:#000000">() </span>// where T: Initable, of course</div></div><div><br></div></blockquote><div> is valid code. Do you know what else is valid?</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><div style="margin:0px;line-height:normal"><span style="color:#bb2ca2">var</span><span style="color:#000000"> x = </span><span style="color:#4f8187">Variable</span><span style="color:#000000"><</span><span style="color:#703daa">Int</span><span style="color:#000000">>() </span>// Hooray! Default values!</div><div><br></div></div></div></blockquote><div>Yet, despite the fact that, from the API user’s point of view, `Variable` already has everything it needs to conform to `Initable`, you can’t write “extension Variable : Initable” without either getting a non-conformance error or, if you then add init() { fatalError() }, getting an “ambiguous expression” error wherever you actually try to call Variable(). And this is the bug: If your protocol `Foo` has a function `foo(X)`, and your type has a function `foo(Y)` <i>where Y can be turned into X through the use of default parameters</i>, then it’s impossible for your type to conform to `Foo`, even though you could use it as a `Foo` in your code. In practice, I think this only matters if you’re using “macros” like <span style="color:rgb(187,44,162)">__LINE__</span> or something as your default parameter, but it’s still annoying (to me, anyway).</div><div><font face="Menlo"><span style="font-size:11px"><br></span></font></div><div>I think we might be able to kill two birds with one stone here… What if protocol conformance had to be declared <i>and</i> it was done implicitly for anything for which there was already a perfect match?</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(187,44,162)">extension<span style="color:#000000"> </span><span style="color:#703daa">Int</span><span style="color:#000000"> : </span><span style="color:#4f8187">Initable</span><span style="color:#000000"> {</span></div></div><div><div style="margin:0px;line-height:normal"><font face="Menlo"><span style="font-size:11px"> </span></font><span style="font-family:Menlo;font-size:11px;color:rgb(0,132,0)">// Implicitly generated because Int.init() (</span><font color="#008400" face="Menlo"><span style="font-size:11px">with no default parameters) already exists</span></font></div><div style="margin:0px;line-height:normal"><span style="font-family:Menlo;font-size:11px;color:rgb(187,44,162)"> </span><font color="#bb2ca2" face="Menlo"><span style="font-size:11px">conformance</span></font><font face="Menlo"><span style="font-size:11px"> </span></font><font face="Menlo"><span style="font-size:11px">{</span></font></div><div style="margin:0px;line-height:normal"><font color="#008400" face="Menlo" style="font-family:Menlo;font-size:11px"><span style="white-space:pre-wrap"> </span>//(protocol_identifier).(requirement_indentifer) = (</font><font color="#008400" face="Menlo"><span style="font-size:11px">expression)</span></font></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> <span style="color:rgb(79,129,135)">Initable</span>.<span style="color:rgb(187,44,162)">init</span>() = <span style="color:rgb(187,44,162)">init</span>() <span style="color:rgb(0,132,0)">// or really any expression that evaluates to an Int</span></div><div style="margin:0px;line-height:normal"><span style="font-family:Menlo;font-size:11px"> </span><span style="font-family:Menlo;font-size:11px">}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">}</div></div></blockquote><div><br></div><div>Then we could get both your default parameter support (I think) <i>and</i> fix this “bug of non-intuitivity” (which people keep telling me isn’t really a bug because of what protocols <i>actually</i> mean*) simply by being able to explicitly write it out:</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div style="font-family:Menlo;font-size:11px;margin:0px;line-height:normal"><span style="color:rgb(187,44,162)">class</span> Variable <T: Initable> : <span style="color:rgb(79,129,135)">Initable </span>{</div></div><span style="color:rgb(0,132,0);font-family:Menlo;font-size:11px"> // Must be explicitly written, since in this case there</span><font color="#008400" face="Menlo"><span style="font-size:11px">’s no literal match</span></font><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> <span style="color:rgb(187,44,162)">conformance</span> {</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> <span style="color:rgb(79,129,135)">Initable.</span><span style="color:rgb(187,44,162)">init</span>() = <span style="color:rgb(187,44,162)">init</span>(<span style="color:rgb(187,44,162)">_</span> value: <span style="color:rgb(112,61,170)">T</span>, path: <span style="color:rgb(112,61,170)">String</span> = <span style="color:rgb(187,44,162)">__FILE__</span>, line: <span style="color:rgb(112,61,170)">Int</span> = <span style="color:rgb(187,44,162)">__LINE__</span>)</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> }</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> …</div><div style="font-family:Menlo;font-size:11px;margin:0px;line-height:normal">}</div></div></blockquote><div><br></div><div>In theory, we could also use this for optimizations:</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><div style="margin:0px;line-height:normal"><div style="margin:0px;line-height:normal"><font color="#bb2ca2">private let </font>_default_int_: <span style="color:rgb(112,61,170)">Int </span>=<font color="#bb2ca2"> </font><span style="color:rgb(39,42,216)">0</span></div></div></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(187,44,162)">extension<span style="color:rgb(0,0,0)"> </span><span style="color:rgb(112,61,170)">Int</span><span style="color:rgb(0,0,0)"> : </span><span style="color:rgb(79,129,135)">Initable</span><span style="color:rgb(0,0,0)"> {</span></div></div><div><div style="margin:0px;line-height:normal"><span style="font-family:Menlo;font-size:11px;color:rgb(187,44,162)"> </span><font color="#bb2ca2" face="Menlo"><span style="font-size:11px">conformance</span></font><font face="Menlo"><span style="font-size:11px"> </span></font><font face="Menlo"><span style="font-size:11px">{</span></font></div><div style="margin:0px;line-height:normal"><font face="Menlo"><span style="font-size:11px"> </span></font><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)">Initable</span><font face="Menlo"><span style="font-size:11px">.</span></font><span style="font-family:Menlo;font-size:11px;color:rgb(187,44,162)">init</span><font face="Menlo"><span style="font-size:11px">() = </span></font><span style="color:rgb(79,129,135);font-family:Menlo;font-size:11px">_default_int_</span><font face="Menlo"><span style="font-size:11px"> </span></font><span style="font-family:Menlo;font-size:11px;color:rgb(0,132,0)">//why bother with a function call when you could substitute a constant?</span></div><div style="margin:0px;line-height:normal"><span style="font-family:Menlo;font-size:11px"> </span><span style="font-family:Menlo;font-size:11px"> </span><span style="font-family:Menlo;font-size:11px">}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">}</div></div><div><br></div></blockquote></div><div><br></div><div>I don’t know how deep into the compiler this “conformance” clause would have to be carried… The generic specializer would certainly need it, but I don’t know enough about how that works to say how much this would actually change anything…</div><div><div><br></div><div>- Dave Sweeris</div></div><div><br></div><div>* Yes, I know that protocol conformance is about the <i>actual</i> function signatures and not just what the compiler can deduce… My point is that, IMHO, it’s counter-intuitive to be able to get the same “user-level” signature, but not be able to semantically express that to the compiler.</div><div><div class="h5"><div><br></div><div><div><blockquote type="cite"><div>On Jan 16, 2016, at 03:35, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="auto"><div>I still think that, except in certain very generic cases, default methods are something I would be wary of being easily abused.</div><div><br></div><div>Protocols, Java style interfaces, they allow users to focus only on a generic behaviour/contract without having to rely or being able to rely and/or make bonding assumptions on any implementation details of the type conforming to the protocol. Default methods in a protocol still seem to go in the opposite direction although they do offer a lot of convenience and open up new styles.<br><br>Sent from my iPhone</div><div><br>On 16 Jan 2016, at 11:04, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div>I think that the point of allowing defaults in protocols is so that you can assume a default for all types conforming to that protocol. To use your example, if you receive an instance of Name, you can only call printSomething() without arguments if you test that it is an instance of type Name. If instead you test its conformance to the Good protocol (which you might do if there are a lot of different types conforming to Good) then you have to provide a value, because you can’t infer that every possible implementation will have a default.</div><div><br></div><div>Regarding this proposal however I think it might be useful to have a distinction between a protocol function that specifies a default value for all implementations (that they must all conform to) versus one that specifies that implementations must have a default value, but not what that value must be.</div><div><br></div><div>For example, to have a fixed and altered default we currently we have to do things like this:</div><div><br></div><div><div>protocol Protocol {</div><div><span style="white-space:pre-wrap"> </span>func functionWithSpecificDefault(argument:String)</div><div><span style="white-space:pre-wrap"> </span>func functionWithAnyDefault(argument:String)</div><div>}</div></div><div><br></div><div>extension Protocol {</div><div><span style="white-space:pre-wrap"> </span>func functionWithSpecificDefault() { self.functionWithSpecificDefault(“Foo”) }</div><div><span style="white-space:pre-wrap"> </span>func functionWithAnyDefault() { self.functionWithAnyDefault(“Foo”) }</div><div>}</div><div><br></div><div>class MyClass : Protocol {</div><span style="white-space:pre-wrap"> </span>func functionWithSpecificDefault(argument:String) { /* Implementation here */ }<div><span style="white-space:pre-wrap"> </span>func functionWithAnyDefault(argument:String) { /* Implementation here */ }</div><div><br><div><span style="white-space:pre-wrap"> </span>func functionWithAnyDefault() { self.functionWithAnyDefault(“Bar”) } // Override default</div><div>}</div><div><br></div><div>Which could be replaced by:</div><div><br></div><div>protocol Protocol {</div><div><span style="white-space:pre-wrap"> </span>func functionWithSpecificDefault(argument:String = “Foo")</div><div><span style="white-space:pre-wrap"> </span>func functionWithAnyDefault(argument:String = default)</div><div>}</div><div><br></div><div>class MyClass : Protocol {</div><span style="white-space:pre-wrap"> </span>func functionWithSpecificDefault(argument:String = “Foo") { /* Implementation here */ }<div><span style="white-space:pre-wrap"> </span>func functionWithAnyDefault(argument:String = “Bar") { /* Implementation here */ }</div><div>}</div><div><br></div><div>However, this has the added advantage that implementing functionWithSpecificDefault with a default other than “Foo” would cause a compiler error, while doing so for functionWithAnyDefault would not (but specifying no default at all would, as one is required).</div><br><div><blockquote type="cite"><div>On 16 Jan 2016, at 10:15, 肇鑫 via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">No. Although you protocol's function doesn't has a default parameter value. Your implementation does. So you don't need to define another func function() in your protocol.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default"><div class="gmail_default"><font face="georgia, serif">protocol Good {</font></div><div class="gmail_default"><font face="georgia, serif"> func printSomething(something:String)</font></div><div class="gmail_default"><font face="georgia, serif">}</font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><div class="gmail_default"><font face="georgia, serif">struct Name:Good {</font></div><div class="gmail_default"><font face="georgia, serif"> func printSomething(something: String = "John") {</font></div><div class="gmail_default"><font face="georgia, serif"> print(something)</font></div><div class="gmail_default"><font face="georgia, serif"> }</font></div><div class="gmail_default"><font face="georgia, serif">}</font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><div class="gmail_default"><font face="georgia, serif">Name().printSomething()</font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><div class="gmail_default"><font face="georgia, serif">above code works.</font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><div class="gmail_default"><font face="georgia, serif">zhaoxin</font></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 16, 2016 at 6:05 PM, Vatsal Manot <span dir="ltr"><<a href="mailto:vatsal.manot@yahoo.com" target="_blank">vatsal.manot@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>It serves as a better (if not simpler) substitute for the following pattern:</div><div> </div><span>protocol Protocol<br></span><span>{<br></span><span> typealias Argument<br></span><span> <br></span><span> func function()<br></span><span> func function(_: Argument)<br></span><div><div><span>}<br></span><span> <br></span><div><div><blockquote type="cite"><div>On 16-Jan-2016, at 3:29 PM, 肇鑫 <<a href="mailto:owenzx@gmail.com" target="_blank">owenzx@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">I wonder where is the good for a protocol designer on this?<br></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">zhaoxin</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 16, 2016 at 5:23 PM, Vatsal Manot via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently, the following the code fails with multiple errors:<br>
<br>
protocol Protocol<br>
{<br>
typealias Argument<br>
<br>
func function(argument: Argument = default)<br>
}<br>
<br>
I propose that we allow protocols to require functions with default parameter values. I can’t see any disadvantages to this, and the change would only be additive.<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><br>Owen Zhao<br></div></div></div>
</div></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><br>Owen Zhao<br></div></div></div>
</div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>