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 [email protected] 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
