[swift-evolution] [Pitch] Allow trailing argument labels

Derrick Ho wh1pch81n at gmail.com
Sun Feb 26 12:41:21 CST 2017


-1 to this proposal.

While it is true that adding the argument labels helps you "read" it
better, you end up with an inverted binary operator.  I'll call it a
sandwich.

Argument labels should be used to name an argument so the fact that there
is no argument provided means that this is not a good use case.

I prefer the work around where you accept a void argument.

func something(_ n: Int, strange: Void) { ... }

Then we people look at the definition they can see that it expects a void!

They can call it like this

something(8, strange: ())

in conclusion, I do not support the original pitch.  Argument labels should
be used for arguments.

On Wed, Feb 22, 2017 at 9:22 AM Haravikk <swift-evolution at haravikk.me>
wrote:

>
> On 22 Feb 2017, at 13:19, Derrick Ho <wh1pch81n at gmail.com> wrote:
>
> I've read the pitch, but it isn't clear what the ask is or what benefit it
> would give.
>
>
> The purpose of the feature is to enable selection of identically named
> methods with similar signatures. This came up in the protocol-oriented
> integers debate on the ability to have arithmetic methods with and without
> overflow. Like so:
>
> protocol IntegerArithmetic {
> func adding(_ other:Self) -> Self
> func adding(_ other:Self, reportingOverflow) -> (Self, Bool)
> }
>
> var a = 2, b = 3
> let resultWithoutOverflow = a.adding(b)
> let resultWithOverflow = a.adding(b, reportingOverflow)
>
> Here we have two different methods, one reporting overflow and one
> without, using the label to enable selection, rather than having to have an
> addingWithOverflow() method or similar.
>
> Currently the alternative is to do something like:
>
> enum ReportingOverflow { case .reportingOverflow }
> protocol IntegerArithmetic {
> func adding(_ other:Self) -> Self
> func adding(_ other:Self, _) -> (Self, Bool)
> }
>
> var a = 2, b = 3
> let resultWithoutOverflow = a.adding(b)
> let resultWithOverflow = a.adding(b, .reportingOverflow)
>
> Basically the ability to use the label for method selection is an
> alternative to either defining an enum as above, or having to use a
> different method name.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170226/cfceb6e8/attachment.html>


More information about the swift-evolution mailing list