> On Jun 30, 2016, at 11:43 AM, Scott James Remnant via swift-evolution > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
