I think it squares up relatively well against the Swift 5 standards:
* It addresses ABI stability and strings, which are both Swift 5 themes.
* It includes an implementation, but it definitely needs a rebase, probably needs someone more experienced than me to examine it with a fine-toothed comb, and might need a significant redesign.
* I believe it includes tests.
* I don't think it's been run against the source compatibility suite. (Is there a way for random outside developers to do that?)
I like the proposal so far and would be happy seeing this in 4.1, even.
;) I don’t know/remember the conditions under which the previous
implementation was deemed unsuitable, but this addresses most of my
personal qualms with it.
My primary interests in an interpolation align with yours: in addition
to things like SQL statements, I want string literals to improve aspects
of Apple’s frameworks like localization and (especially of interest to
me) logging. The `StringInterpolationSegment` design allows those
interests to be satisfied by limiting the acceptable interpolation
types, which is pretty nice. At the compiler QoL level, the error
handling for this will have to be pretty spiffy though.
My only suggestion for proposed given design would be to consider making
`case interpolation(Interpolation)` take a `() throws -> Interpolation`
instead to allow for lazy evaluation, basically acting like an
autoclosure. In your SQLStatement
I actually don’t mind the buffer approach; it aligns reasonably with
Codable’s semantics. I understand the cons there are significant. It
comes down to extensibility; the proposed design is reasonable if we
can’t think of any potential ways to extend interpolation, since the
segment enum will have to be closed.
Sincerely,
Zachary Waldowski
zach@waldowski.me
···
On Wed, Aug 9, 2017, at 12:08 AM, Brent Royal-Gordon via swift-evolution wrote:
I think it squares up relatively well against the Swift 5 standards:
* It addresses ABI stability and strings, which are both Swift 5 themes.
* It includes an implementation, but it definitely needs a rebase,
probably needs someone more experienced than me to examine it with a
fine-toothed comb, and might need a significant redesign.
* I believe it includes tests.
* I don't think it's been run against the source compatibility suite. (Is
there a way for random outside developers to do that?)
This is an excellent proposal; no suggestions for improvement at this
point, as I think it has evolved excellently from its earlier forms. I hope
it goes swiftly to review.
···
On Tue, Aug 8, 2017 at 11:08 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:
I had a proposal for replacing/reintroducing `
ExpressibleByStringInterpolation` (which is currently deprecated pending
a redesign), but it landed too late in the Swift 4 cycle to be considered.
The PR is here: https://github.com/apple/swift-evolution/pull/659
I think it squares up relatively well against the Swift 5 standards:
* It addresses ABI stability and strings, which are both Swift 5 themes.
* It includes an implementation, but it definitely needs a rebase,
probably needs someone more experienced than me to examine it with a
fine-toothed comb, and might need a significant redesign.
* I believe it includes tests.
* I don't think it's been run against the source compatibility suite. (Is
there a way for random outside developers to do that?)