Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Final: Implementation for SE-0228: Fix ExpressibleByStringInterpolation #20214
This PR implements a new string interpolation API with a different, finalized ABI from what we're currently shipping.
This is #19963 with a clean revision history and a final pass for style. The only functional changes are that
I expect the final checks to still show some benchmark regressions. A few are known issues with non-ABI-affecting fixes planned. The others we think will be easier to fix on master, where we can coordinate changes more easily.
Build comment file:
Code size: -O
Code size: -Osize
Code size: Swift libraries
How to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein).
Alamofire failed to compile Source/MultipartFormData.swift line 95. It's using a string interpolation in a weird way—in an initializer for a lazy property, interpolating the value of a non-lazy property—which is causing its temporary to become immutable for some reason.
Unfortunately, I haven't been able to reproduce it yet, even by downloading and compiling the entire project locally. The console indicates that Alamofire did fail in CI release mode too, though. Perhaps my setup isn't a precise enough reproduction of the CI environment.
I really wanted to get this in tonight, but I guess it'll have to wait for tomorrow. The other CI results don't concern me; the performance benchmarks are showing both more regressions and more improvements, so either the CI is being weird tonight or something recently landed (like BuiltinInt) that shifted performance around in complicated ways. Either way, it's not a good reason to not merge.
(If someone with a little more seniority than me wants to merge this despite the source compatibility failure, go ahead. I may be too conservative about this.)
Nov 3, 2018
Just a drive by commentary of some things I should of caught in the review. Don't worry about changing this, I'm trying to incorporate this into the UTF-8 branch and wouldn't want churn here.
We can discuss the details over a whiteboard if you like