Disambiguate Return Type With Void


(Anton Zhilin) #1

+1

Also, technically we can assign a value to Void function

This proposal will not disallow that. Just non-Void functions will be
preferred when result is used.

array.sort(..) // mutating
let array2 = array.sort(..) // non-mutating, instead of array.sorted()

I think, that's actually the best solution to mutating / non-mutating
convention!

Andrew, why not generalize this proposal to functions with @unusedResult?

In terms of "precedence" when result is used:
Non-Void > @unusedResult > Void (+warning)

When unused:
Void > @unusedResult > Non-Void (+warning)

- Anton


(Jordan Rose) #2

There are mutating methods that have return values, like Dictionary.removeValue(forKey:). Admittedly there’s no non-mutating version of that at the moment, but that doesn’t mean there couldn’t be.

Jordan

···

On Apr 26, 2016, at 06:57, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

+1

> Also, technically we can assign a value to Void function
This proposal will not disallow that. Just non-Void functions will be preferred when result is used.
array.sort(..) // mutating
let array2 = array.sort(..) // non-mutating, instead of array.sorted()
I think, that's actually the best solution to mutating / non-mutating convention!


(Anton Zhilin) #3

Let's expand on that situation. Dictionary would have these methods:

@discardableResult func removeValue(forKey key: Key) -> Value?
func removeValue(forKey key: Key) -> Self

I would argue that these two versions are not semantically identical: (1)
returns removed value while (2) does not.
Therefore they should have different names. In this case, we can rename
them like this:

@discardableResult func removeValue(forKey key: Key) -> Value?
func remove(key key: Key) -> Self

Or like this:

func removeValue(forKey key: Key) -> Value?
func remove(key key: Key) -> Void
func remove(key key: Key) -> Self

- Anton

···

2016-04-26 19:26 GMT+03:00 Jordan Rose <jordan_rose@apple.com>:

On Apr 26, 2016, at 06:57, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:

+1

> Also, technically we can assign a value to Void function
This proposal will not disallow that. Just non-Void functions will be
preferred when result is used.

array.sort(..) // mutating
let array2 = array.sort(..) // non-mutating, instead of array.sorted()

I think, that's actually the best solution to mutating / non-mutating convention!

There are mutating methods that have return values, like
Dictionary.removeValue(forKey:). Admittedly there’s no non-mutating version
of that at the moment, but that doesn’t mean there couldn’t be.

Jordan


(Andrew Bennett) #4

I'm happy to add `@unusedResult`, with a little more discussion. I'm not
sure when it would actually be used though.

I'm not sure if you can define both of these functions:

   @unusedResult func example() -> Int
   func example() -> Int

Either way, a method with @unusedResult should probably have a different
name to one without.

You can define both of these functions:

   @unusedResult func example() -> Int
   func example() -> String

However, if the methods return different non-void values they should
probably have different names.

···

On Tue, Apr 26, 2016 at 11:57 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

+1

> Also, technically we can assign a value to Void function
This proposal will not disallow that. Just non-Void functions will be
preferred when result is used.

array.sort(..) // mutating
let array2 = array.sort(..) // non-mutating, instead of array.sorted()

I think, that's actually the best solution to mutating / non-mutating convention!

Andrew, why not generalize this proposal to functions with @unusedResult?

In terms of "precedence" when result is used:
Non-Void > @unusedResult > Void (+warning)

When unused:
Void > @unusedResult > Non-Void (+warning)

- Anton


(Anton Zhilin) #5

Agreed. That would only allow to disambiguate call with unused result, but
would not solve this problem. Jordan pointed at it.
It would be consistent therefore to leave @discardableResult functions with
usual non-Void functions.

- Anton

···

2016-04-27 12:01 GMT+03:00 Andrew Bennett <cacoyi@gmail.com>:

I'm happy to add `@unusedResult`, with a little more discussion. I'm not
sure when it would actually be used though.

I'm not sure if you can define both of these functions:

   @unusedResult func example() -> Int
   func example() -> Int

Either way, a method with @unusedResult should probably have a different
name to one without.

You can define both of these functions:

   @unusedResult func example() -> Int
   func example() -> String

However, if the methods return different non-void values they should
probably have different names.

On Tue, Apr 26, 2016 at 11:57 PM, Антон Жилин <antonyzhilin@gmail.com> > wrote:

+1

> Also, technically we can assign a value to Void function
This proposal will not disallow that. Just non-Void functions will be
preferred when result is used.

array.sort(..) // mutating
let array2 = array.sort(..) // non-mutating, instead of array.sorted()

I think, that's actually the best solution to mutating / non-mutating convention!

Andrew, why not generalize this proposal to functions with @unusedResult?

In terms of "precedence" when result is used:
Non-Void > @unusedResult > Void (+warning)

When unused:
Void > @unusedResult > Non-Void (+warning)

- Anton