As an addendum to this:
If it’s important that the variable be invoked with argument labels, that can
be provided by having argument labels as part of the variable’s name:
func foo(a: A, b: B) -> C
func bar(from: A, using: B) -> C
// ...
let myA : A = …
let myB : B = ...
var higherOrderABToC(with:until:) : (A, B) -> C = foo(a:b:)
var myC = higherOrderABToC(with: myA, until: myB)
higherOrderABToC = bar(from:using:)
myC = higherOrderABToC(with: myA, until: myB)
> On Jun 30, 2016, at 4:16 PM, Michael Ilseman via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I didn’t see the pre-proposal, and I apologize if this has come up elsewhere
> on this list, but did you consider the alternative where you must use the
> compound name to refer to a function? That is:
>
> func foo(a: A, b: B) -> C
> func bar(from: A, using: B) -> C
> let higherOrderABToC: (A, B) -> C = foo(a:b:)
> higherOrderABToC = bar(from:using:)
>
> That is, “foo” by itself is an incomplete name, and you must provide the full
> compound name. This will penalize convenience of references to functions,
> though you will simplify the overloading logic of functions: two functions
> are not overloaded if their full compound names differ. This can be thought
> of as taking SE0021 and running wild, enforcing that all naming of functions
> use the compound name.
>
> The notion of providing the name of a function with a full compound name is
> increasingly common in Swift, with SE0021 generalized naming, improvements to
> swift_name, SE0044 import-as-member, etc.
>
> To modify the example from later in the proposal:
>
> func doSomething(x: Int, y: Int) -> Bool {
> return x == y
> }
>
> func somethingElse(a: Int, b: Int) -> Bool {
> return a > b
> }
>
> // fn2's type is (Int, Int) -> Bool
> var fn2 = doSomething(x:y:)
>
> // Okay
> fn2(1, 2)
>
> // Okay
> fn2 = somethingElse(a:b:)
>
> The notion here, is that we’re not just dropping argument labels from the
> type system, but instead we’re hoisting such concerns into the syntax by
> making them an intrinsic part of the name. Then, if you bind to it with a
> value, that value of course wouldn’t be called with labels because labels are
> not part of its name.
>
> If this is unwieldy, then it’s worth stating how this behaves in the presence
> of functions overloaded based on argument label alone, as Erica mentions.
>
>
>> On Jun 30, 2016, at 3:43 PM, Austin Zheng <austinzh...@gmail.com
>> <mailto:austinzh...@gmail.com>> wrote:
>>
>> 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@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>> On Jun 30, 2016, at 11:43 AM, Scott James Remnant via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <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
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>
> _______________________________________________
> 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
