<br><br>On Wednesday, 27 April 2016, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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'm glad we are on the same page, please let me know if there'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">
"method names help distinguish mutating and non-mutating methods."..<br>
Just some my thoughts: I'm very skeptical in general on this. Personally I probably prefer some kind of explicit "marker" on mutating methods(like foo&.sort()), as I don'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'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's room to improve that. I don't think it'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've put my responses inline:<br>
<br>
On Tue, Apr 26, 2016 at 10:26 PM, Vladimir.S via swift-evolution<br>
<<a>swift-evolution@swift.org</a> <mailto:<a>swift-evolution@swift.org</a>>> 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'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're right, although I don't think there would be a worthwhile loss of<br>
functionality if that statement chose a non-Void function, or didn't store<br>
the result. I'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't change how functions are resolved when there is no ambiguity.<br>
<br>
<br>
On 26.04.2016 13 <tel:26.04.2016%2013>: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'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 <<a>cacoyi@gmail.com</a><br>
<mailto:<a>cacoyi@gmail.com</a>><br>
<mailto:<a>cacoyi@gmail.com</a> <mailto:<a>cacoyi@gmail.com</a>>>> 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't be resolved without<br>
explicitly specifying the type.<br>
<br>
|func example() { ... } func example() -> 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>
<<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>><br>
of<br>
the proposal.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a> <mailto:<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>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a> <mailto:<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>
<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>