> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution
> <[email protected]> wrote:
>
>
> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel <[email protected]
> <mailto:[email protected]>> wrote:
> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> On Thu, Jun 15, 2017 at 17:43 David Hart <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> By the way, I’m not attempting to deduce that nobody uses this feature by
>> the fact I didn’t know about it. But I think it’s one interesting datapoint
>> when comparing it to SE-0110.
>>
>>
>> SE-0110, **in retrospect**, has had impacts on a lot of users;
>> prospectively, it was thought to be a minor change, even after review and
>> acceptance.
>>
>> Keep in mind that this proposed change would also eliminate inline tuple
>> shuffle. For instance, the following code will cease to compile:
>>
>> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
>> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>> print(color)
>> }
>> f(color: x)
>>
>> It is an open question how frequently this is used. But like implicit tuple
>> destructuring, it currently Just Works(TM) and users may not realize they’re
>> making use of the feature until it’s gone.
>
> It's much much less used, by looking at open source projects I doubt that a
> significant portion of projects would have to change code because of this.
>
> The reason that I’m urging caution is because, if I recall correctly, that is
> also what we said about SE-0110 on this list. Then, as now, we were
> discussing an issue with something left over from the Swift 1 model of
> tuples. Then, as now, we believed that the feature in question was rarely
> used. Then, as now, we believed that removing that feature would improve
> consistency in the language, better both for the compiler and for users.
> Then, as now, leaving it in was thought to prevent moving forward with other
> features that could improve Swift.
Data:
I hacked up a regexp that will catch most uses of labeled tuples in pattern
matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking about, right?
I ran that against all 55 projects in swift-source-compat-suite, comprising
about over 400,000 lines of Swift code, and found … drumroll … exactly one
match:
neota (swift-source-compat-suite)$ find project_cache -name '*.swift' -print0 |
xargs -0 pcregrep -M '(for|case|let|var|catch)\s+\([a-zA-Z0-9_]+\s*:'
project_cache/RxSwift/RxExample/RxExample-iOSTests/TestScheduler+MarbleTests.swift:
let (time: _, events: events) = segments.reduce((time: 0,
events: [RecordedEvent]())) { state, event in
Caveats about this method:
• My regexp won’t match second and third patterns in a comma-separated let or
case, e.g.:
let a = b, (c: d) = e
• It doesn’t match non-ascii identifiers.
• This experiment only considers labeled tuples in pattern matches, what I took
Chris’s original puzzler to be about. Label-based tuple shuffling is a separate
question.
Still, even if it’s undercounting slightly, one breakage in half a million
lines of code should put to rest concerns about unexpected widespread impact.
(Anything else I’m missing?)
• • •
Aside for those who know the tools out there: what would it take to run
inspections like this against ASTs instead of using a regex? Could we
instrument the compiler as Brent suggested? Or can SourceKit / SourceKitten
give a full AST? Or has anybody written a Swift parser in Swift?
Cheers,
Paul
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
