[swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

[Austin Zheng]

I would think that the naming guidelines are an argument for reducing the
role of argument labels, if any.

This labeled tuple makes sense, because 'x' and 'y' describe the semantic
meaning of each element (Int which represents an x-coordinate):

let myTuple: (x: Int, y: Int)

This also makes sense, because 'hits' and 'runs' describe the semantic
meaning of each argument (Int which represents number of hits):

let a : (hits: Int, runs: Int) -> Bool

This makes absolutely no sense to me:

let b: (ofHits: Int, forRuns: Int) -> Bool

In fact, 'b' is a better example than the average, because of the naming
guideline point to spell out the semantics of weakly typed arguments in the
argument label.

func getWidget(for provider: Provider, with manifest: ShippingManifest) ->
Widget { /* ... */ }

let widgetGetter : (for: Provider, with: ShippingManifest) = getWidget

At this point, the labels are completely superfluous. They make no sense
except in the context of a method name, because they are prepositional
phrases. Knowing that the Provider is "for" something and something does
something "with" the ShippingManifest is absolutely useless to anyone
reading the code where the method name those labels are part of isn't
immediately obvious.

Austin

On Thu, Jun 30, 2016 at 3:33 PM, Michael Ilseman via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jun 30, 2016, at 11:43 AM, Scott James Remnant via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> -1
>
> This proposal doesn’t even use Swift naming style to make its point, as
> soon as you do, the reason why Swift considers argument labels to be part
> of the type signature becomes apparent.
>
> The author of the proposal uses the following example:
>
>  func doSomething(x: Int, y: Int) -> Bool
>
>
> This is just not Swift-y, a much better example would be:
>
>  func sinkBattleship(atX x: Int, y: Int) -> Bool
>
>
> <pedanticism>
> If you want to talk about pedantic following of API naming guidelines for
> example code, then I believe that your example also runs afoul. It would be:
>
> func sinkBattleshipAt(x: Int, y: Int) -> Bool
>
> Due to a special case where the preposition covers multiple arguments.
> This arrises mostly from flatten-ed structs as parameters, e.g. from old C
> APIs predating struct literal syntax. See:
>
>
>    -
>
>    An exception arises when the first two arguments represent parts of a
>    single abstraction.
>
>    a.move(*toX:* b, *y:* c)
>    a.fade(*fromRed:* b, *green:* c, *blue:* d)
>
>    In such cases, begin the argument label *after* the preposition, to
>    keep the abstraction clear.
>
>    a.moveTo(*x:* b, *y:* c)
>    a.fadeFrom(*red:* b, *green:* c, *blue:* d)
>
>
>
> </pedanticism>
>
>
>
>
> the proposal states that the argument labels be then stripped from the
> type, which would make this method type-compatible with:
>
>  func meetsBattingAverage(ofHits hits: Int, forRuns runs: Int) -> Bool
>
>
> I don’t think it’s desirable for this to work at all… Argument labels are
> not parameter names, they are a first class part of Swift’s type system,
> and always meaningful when employed properly.
>
>
> Scott
> _______________________________________________
> 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/20160630/48e95e5e/attachment.html>