Disambiguate Return Type With Void

Andrew · March 28, 2016, 8:21am

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:

github.com

therealbnut/swift-evolution/blob/andrew-disambiguate-return-type/proposals/0000-disambiguate-return-type.md

# Disambiguate Return Type With Void

* Proposal: [SE-NNNN](https://github.com/therealbnut/swift-evolution/blob/andrew-disambiguate-return-type/proposals/0000-disambiguate-return-type.md)
* Author(s): [Andrew Bennett](https://github.com/therealbnut)
* Status: **Awaiting review**
* Review manager: TBD

## Introduction

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.

This file has been truncated. show original

This is the original version
<https://github.com/therealbnut/swift-evolution/blob/59d0f0b9bdabcfd675f36824232a8efa4a5f9152/proposals/0000-disambiguate-return-type.md>
of
the proposal.

Andrew · April 26, 2016, 10:56am

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

VladimirS · April 26, 2016, 12:26pm

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()

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 == ()

···

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@gmail.com > <mailto:cacoyi@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Andrew · April 26, 2016, 1:04pm

Hi Vladimir, thanks for your feedback, I've put my responses inline:

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 Tue, Apr 26, 2016 at 10:26 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:

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@gmail.com >> <mailto:cacoyi@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

VladimirS · April 26, 2016, 2:19pm

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@swift.org <mailto:swift-evolution@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@gmail.com > <mailto:cacoyi@gmail.com> > <mailto:cacoyi@gmail.com <mailto:cacoyi@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@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

Andrew · April 26, 2016, 2:46pm

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 Wednesday, 27 April 2016, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:

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@swift.org <mailto:swift-evolution@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@gmail.com >> <mailto:cacoyi@gmail.com> >> <mailto:cacoyi@gmail.com <mailto:cacoyi@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@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution