<br><br>On Wednesday, 27 April 2016, Vladimir.S via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Andrew, thanks for comments. Yes, right now I see your points : its not about mutation, but about the result type of the method/function with the same mutation. I fully support this idea, as Swift allows to define the same methods with just different types - we need handy way to call such functions and clear rules when each one will be selected.<br>
<br></blockquote><div>I&#39;m glad we are on the same page, please let me know if there&#39;s some way I can clarify the proposal :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&quot;method names help distinguish mutating and non-mutating methods.&quot;..<br>
Just some my thoughts: I&#39;m very skeptical in general on this. Personally I probably prefer some kind of explicit &quot;marker&quot; on mutating methods(like foo&amp;.sort()), as I don&#39;t fully believe in idea of clear separation based on naming rules. Not all, who will write open source libraries/projects, are native English speakers and we&#39;ll have code where it will be hard to distinguish based on names. Even in this swift-evolution list we have a lot of discussions about right naming of the methods/functions in API..<br>
<br></blockquote><div>I agree, there&#39;s room to improve that. I don&#39;t think it&#39;s in scope for this proposal though, unless you feel this propasal causes issues.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 26.04.2016 16:04, Andrew Bennett wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Vladimir, thanks for your feedback, I&#39;ve put my responses inline:<br>
<br>
On Tue, Apr 26, 2016 at 10:26 PM, Vladimir.S via swift-evolution<br>
&lt;<a>swift-evolution@swift.org</a> &lt;mailto:<a>swift-evolution@swift.org</a>&gt;&gt; wrote:<br>
<br>
    Interesting suggestion, but IMO this will produce a question about new<br>
    naming conversion in Swift 3.0 (noun/verb, -ing/-ed, etc) because using<br>
    your suggestion we could want to use:<br>
<br>
    array.sort(..) // mutating<br>
    let array2 = array.sort(..) // non-mutating, instead of array.sorted()<br>
<br>
<br>
This proposal does not want to change any naming guidelines. The reasons<br>
for those guidelines is good, and remains the same. One reason is that<br>
method names help distinguish mutating and non-mutating methods.<br>
<br>
I&#39;m happy to discuss making the proposal only apply to functions with the<br>
same mutability if that alleviates your concern.<br>
<br>
    Also, technically we can assign a value to Void function(yes, compiler<br>
    warning will be produced, but just warning, not error):<br>
<br>
    var something = array.sort(..) // mutating,currently this is valid code<br>
    // something  == ()<br>
<br>
<br>
You&#39;re right, although I don&#39;t think there would be a worthwhile loss of<br>
functionality if that statement chose a non-Void function, or didn&#39;t store<br>
the result. I&#39;m not sure why you would want to store the Void.<br>
<br>
Note that this proposal is only to resolve ambiguity *if* there is any :)<br>
It won&#39;t change how functions are resolved when there is no ambiguity.<br>
<br>
<br>
    On 26.04.2016 13 &lt;tel:26.04.2016%2013&gt;:56, Andrew Bennett via<br>
    swift-evolution wrote:<br>
<br>
        Hey,<br>
<br>
        I thought I would post another message to this thread because I<br>
        think it<br>
        was missed when I first sent it (I made the mistake of sending it<br>
        at 1am<br>
        San Francisco time, I&#39;m in Australia).<br>
<br>
        I appreciate any feedback :)<br>
<br>
        Thanks,<br>
        Andrew<br>
<br>
        On Mon, Mar 28, 2016 at 7:21 PM, Andrew Bennett &lt;<a>cacoyi@gmail.com</a><br>
        &lt;mailto:<a>cacoyi@gmail.com</a>&gt;<br>
        &lt;mailto:<a>cacoyi@gmail.com</a> &lt;mailto:<a>cacoyi@gmail.com</a>&gt;&gt;&gt; wrote:<br>
<br>
            Swift can resolve functions based on the return type. However,<br>
        when the<br>
            result is unused a single function often can&#39;t be resolved without<br>
            explicitly specifying the type.<br>
<br>
            |func example() { ... } func example() -&gt; Int { ... } example()<br>
        as Void<br>
            example() as Int |<br>
<br>
            This proposal disambiguates some cases:<br>
<br>
              * Preferring functions with a |*Void*| return type when the<br>
        result<br>
                *is* discarded.<br>
              * Preferring functions with a *non-|Void|* type when the<br>
        result *is<br>
                not* discarded.<br>
<br>
            These example will be unambiguous:<br>
<br>
            |example() // will prefer a `Void` function let x = example()<br>
        // will<br>
            prefer a non-`Void` function|<br>
<br>
            You can read the full latest version of the proposal here:<br>
<br>
<br>
        <a href="https://github.com/therealbnut/swift-evolution/blob/andrew-disambiguate-return-type/proposals/0000-disambiguate-return-type.md" target="_blank">https://github.com/therealbnut/swift-evolution/blob/andrew-disambiguate-return-type/proposals/0000-disambiguate-return-type.md</a><br>
<br>
            This is the original version<br>
<br>
        &lt;<a href="https://github.com/therealbnut/swift-evolution/blob/59d0f0b9bdabcfd675f36824232a8efa4a5f9152/proposals/0000-disambiguate-return-type.md" target="_blank">https://github.com/therealbnut/swift-evolution/blob/59d0f0b9bdabcfd675f36824232a8efa4a5f9152/proposals/0000-disambiguate-return-type.md</a>&gt;<br>
        of<br>
            the proposal.<br>
<br>
<br>
<br>
<br>
        _______________________________________________<br>
        swift-evolution mailing list<br>
        <a>swift-evolution@swift.org</a> &lt;mailto:<a>swift-evolution@swift.org</a>&gt;<br>
        <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
    _______________________________________________<br>
    swift-evolution mailing list<br>
    <a>swift-evolution@swift.org</a> &lt;mailto:<a>swift-evolution@swift.org</a>&gt;<br>
    <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
<br>
</blockquote>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>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>
</blockquote>