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

Charles Srstka cocoadev at charlessoft.com
Thu Jun 30 17:43:30 CDT 2016


> On Jun 30, 2016, at 1:50 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Thu, Jun 30, 2016 at 11:43 AM, Scott James Remnant via swift-evolution <swift-evolution at swift.org <mailto: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
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/00395c9e/attachment.html>


More information about the swift-evolution mailing list