[swift-evolution] ExpressibleByStringInterpolation

[Zach Waldowski]

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 at waldowski.me

On Wed, Aug 9, 2017, at 12:08 AM, Brent Royal-Gordon via swift-evolution
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?)
> 
> So what's the next step at this point?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution