> On Jun 30, 2016, at 1:50 PM, Austin Zheng via swift-evolution > <swift-evolution@swift.org> wrote: > > On Thu, 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 > > 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 > > They already *are* type compatible. This works right now: > > var a : (ofHits: Int, forRuns: Int) -> Bool = meetsBattingAverage > a = sinkBattleship > // ??? > a(ofHits: 1, forRuns: 2)
I’d prefer to tighten the system so that the above no longer compiles, rather than make it even more permissive. -1. Charles
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
