[swift-evolution] Disambiguate Return Type With Void

[Vladimir.S]

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.

"method names help distinguish mutating and non-mutating methods."..
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..

On 26.04.2016 16:04, Andrew Bennett wrote:
> Hi Vladimir, thanks for your feedback, I've put my responses inline:
>
> On Tue, Apr 26, 2016 at 10:26 PM, Vladimir.S via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>     Interesting suggestion, but IMO this will produce a question about new
>     naming conversion in Swift 3.0 (noun/verb, -ing/-ed, etc) because using
>     your suggestion we could want to use:
>
>     array.sort(..) // mutating
>     let array2 = array.sort(..) // non-mutating, instead of array.sorted()
>
>
> This proposal does not want to change any naming guidelines. The reasons
> for those guidelines is good, and remains the same. One reason is that
> method names help distinguish mutating and non-mutating methods.
>
> I'm happy to discuss making the proposal only apply to functions with the
> same mutability if that alleviates your concern.
>
>     Also, technically we can assign a value to Void function(yes, compiler
>     warning will be produced, but just warning, not error):
>
>     var something = array.sort(..) // mutating,currently this is valid code
>     // something  == ()
>
>
> You're right, although I don't think there would be a worthwhile loss of
> functionality if that statement chose a non-Void function, or didn't store
> the result. I'm not sure why you would want to store the Void.
>
> Note that this proposal is only to resolve ambiguity *if* there is any :)
> It won't change how functions are resolved when there is no ambiguity.
>
>
>     On 26.04.2016 13 <tel:26.04.2016%2013>:56, Andrew Bennett via
>     swift-evolution wrote:
>
>         Hey,
>
>         I thought I would post another message to this thread because I
>         think it
>         was missed when I first sent it (I made the mistake of sending it
>         at 1am
>         San Francisco time, I'm in Australia).
>
>         I appreciate any feedback :)
>
>         Thanks,
>         Andrew
>
>         On Mon, Mar 28, 2016 at 7:21 PM, Andrew Bennett <cacoyi at gmail.com
>         <mailto:cacoyi at gmail.com>
>         <mailto:cacoyi at gmail.com <mailto:cacoyi at gmail.com>>> wrote:
>
>             Swift can resolve functions based on the return type. However,
>         when the
>             result is unused a single function often can't be resolved without
>             explicitly specifying the type.
>
>             |func example() { ... } func example() -> Int { ... } example()
>         as Void
>             example() as Int |
>
>             This proposal disambiguates some cases:
>
>               * Preferring functions with a |*Void*| return type when the
>         result
>                 *is* discarded.
>               * Preferring functions with a *non-|Void|* type when the
>         result *is
>                 not* discarded.
>
>             These example will be unambiguous:
>
>             |example() // will prefer a `Void` function let x = example()
>         // will
>             prefer a non-`Void` function|
>
>             You can read the full latest version of the proposal here:
>
>
>         https://github.com/therealbnut/swift-evolution/blob/andrew-disambiguate-return-type/proposals/0000-disambiguate-return-type.md
>
>             This is the original version
>
>         <https://github.com/therealbnut/swift-evolution/blob/59d0f0b9bdabcfd675f36824232a8efa4a5f9152/proposals/0000-disambiguate-return-type.md>
>         of
>             the proposal.
>
>
>
>
>         _______________________________________________
>         swift-evolution mailing list
>         swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>         https://lists.swift.org/mailman/listinfo/swift-evolution
>
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     https://lists.swift.org/mailman/listinfo/swift-evolution
>
>