> Le 7 juin 2017 à 20:33, Gwendal Roué <gwendal.r...@gmail.com> a écrit :
>
> For example, take those three functions:
>
> func f(_ closure:(Int, Int) -> ())
> func g(_ closure:((Int, Int)) -> ())
> func h(_ closure:((a: Int, b: Int)) -> ())
>
> If one can always write (as in Swift 3):
>
> f { (a, b) in ... }
> g { (a, b) in ... }
> c { (a, b) in ... }
>
> Then one can easily deal with a badly fit closure signature.
>
> This is most examplified by dictionaries. They always expose (key: Key,
> value: Value) tuples (their Element type). Problem is that 'key' and 'value'
> are identifiers that only matter for dictionaries, not for dictionary users.
> It's very important for dictionary users to forget about tuples, and the
> `key` and `value` words:
>
> // No pollution
> dictionary.map { (name, score) in ... }
It looks like some people in this mailing list are horrified by this "request"
(not a feature request, but a request that Swift 3 behavior is restored,
actually).
What could be the reasons for such a bad reaction?
1: measurable runtime overhead (slower programs in some cases, without any
obvious way for the developper to notice where is the extra cost)
2: measurable compiler overhead (slower compilation)
3: implementation complexity (slower swift progress, technical debt, etc.)
4: other?
I understand 1. We are all fascinated by C++ and Rust "zero-overhead". If this
is the main concern of the community, then we may focus the discussion of that
very precise topic.
I can live with 2 (just a personal subjective preference)
About 3: I can not tell because I lack the necessary skills.
4: enlighten us!
Gwendal
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
