[swift-evolution] Disambiguate Return Type With Void

[Andrew Bennett]

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> 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: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>> 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
>> 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/20160426/0c3b26be/attachment.html>