[swift-evolution] Disambiguate Return Type With Void

[Andrew Bennett]

On Wednesday, 27 April 2016, Vladimir.S via swift-evolution <
swift-evolution at swift.org> wrote:

> 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.
>
> I'm glad we are on the same page, please let me know if there's some way I
can clarify the proposal :)


> "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..
>
> 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.


> 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
>>
>>
>> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160427/3689fd2b/attachment.html>