+1However, I think it's a shame that with OverloadedStrings the interpolation happens on String and then gets converted with fromString, and I don't really want to use QualifiedStrings. I see there was some discussion about this, including some perf measurements (9x overhead for going via String), but I didn't read the 600+ previous comments(!) so it's not clear to me why this design was chosen over one which allows the interpolation to be specialised. This design introduces a performance pitfall: use Text.s"...", it's 9x faster! This is yet another thing that performance gurus will need to know. Feels a bit unsatisfying.CheersSimon_______________________________________________On Mon, 20 Jul 2026 at 07:12, Sebastian Graf <sgraf1337@gmail.com> wrote:Hi everyone,Thanks to Simon, Rodrigo, Erik and Jaro for expressing their votes.We are now 3 weeks into the review period. That means we have about 1 week left to come to a conclusion. I would be interested in the opinions of
- Simon M
- Adam
- Malte
- Matthías
- Jakob
Thank you!Sebastian_______________________________________________Am Do., 16. Juli 2026 um 18:58 Uhr schrieb <code@jaro.addy.io>:I support the proposal.I think string interpolation is rarely the most principled solution any problem, but it is very convenient and Brandon and all contributors have put enough thought into making sure the proposed string interpolation has few sharp edges.Cheers,JaroOn 29 Jun 2026, at 12:41, Sebastian Graf <sgraf1337@gmail.com> wrote:Dear committee,
In #570, Brandon Chinn proposes adding native string interpolation syntax to GHC, along the lines of s"a ${x + 1} b", catching up with and even exceeding similar features in popular programming languages.I think this is an important proposal and I recommend that we accept it.Since the previous submission, Brandon settled on a coherent and simple interaction with -XOverloadedStrings. Although the proposed interpolation API seems more ad-hoc than necessary, I did not find a way to simplify it any further.Cheers,Sebastian
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org