>
> name <- "world"
> msg <- g("hello ${nane}")> we will not know about that typo until g() is called. I think while it would be a runtime error, tooling around R could catch it. This would actually be a really nice feature for a language server + linter such as `jarl`. P.S. I feel obliged to say this: if this idea is genuinely considered, the name "g-string" may...raise many eyebrows. The more standard f-string or an alternative would be less likely to lead to childish humor (myself obviously not immune). On Mon, Dec 15, 2025 at 10:25 AM Henrik Bengtsson < [email protected]> wrote: > > Would be nice sugar for end users to have... > > A major problem with string interpolation is that it cannot be > validated until run-time unless it's standardized by the language > itself. For instance, if we have > > name <- "world" > msg <- g("hello ${nane}") > > we will not know about that typo until g() is called. Not being able > to catch coding errors until at run-time increases the amount of > luring bugs(*). The 'codetools' code inspection by 'R CMD check' > cannot "reach" into these "dynamic" strings, meaning we risk shipping > broken code. It also prevents static-code inspection at run time, e.g. > identification of variables needed in order to resolve an expression > (useful for parallel processing etc.), much like y <- get(name) hides > things. > > In order to safely introduce string interpolation, I think the best > would be to introduce a standard syntax that would allow for static > code inspection, e.g. g"hello ${nane}". That would make it possible to > validate the string interpolation during parsing, or immediately > after, but before evaluation. > > If this could be handled by the parser, even better, e.g. have > > name <- world" > msg <- g"hello ${nane}" > > be parsed as: > > name <- world" > msg <- paste0("hello ", as.character(nane)) > > This would have zero overhead at run-time, and would be fully > transparent to code inspection and validation tools. That would be > pure syntactic sugar, just like how the base-R pipe LHS |> RHS() is > identical to RHS(LHS). > > (*) If we would do a bug analysis, I'm sure we would find more bugs > where string interpolation is used than where we compose such strings > using traditional paste() methods. I think this would be especially > true for rarely called code lines, e.g. calls to stop(). Anecdotally, > when R introduced built-in validation of the number and types of > sprintf() arguments, it revealed sprintf() bugs in several CRAN and > Bioconductor packages. > > /Henrik > > On Mon, Dec 15, 2025 at 8:16 AM Serguei Sokol via R-devel > <[email protected]> wrote: > > > > Le 15/12/2025 à 16:02, Gabor Grothendieck a écrit : > > > I believe that would require a change to R itself. If you can make do > > > with a workaround then > > > > > > 1. this works but has the drawback that you need to define your own > > > string class. Below fmt > > > is an object with class "mystring". > > > > > > as.mystring <- function(x) structure(x, class = "mystring") > > > "!.mystring" <- glue > > > > > > fmt <- as.mystring("pi = {pi}") > > > !fmt > > > ## pi = 3.14159265358979 > > Nice. > > Which makes me think why not to use "!" on a classical string? Before > > now, it was a meaningless operation so no potential conflicts should > appear. > > > > # setting up > > `!` <- function(x) UseMethod("!") # make generic > > `!.default` <- base::`!` # preserve the old behavior for other classes > > `!.character`=glue::glue # make act as a glue on strings > > > > # usage > > !"pi={pi}" > > # pi=3.14159265358979 > > !FALSE > > # [1] TRUE ## as before > > > > Best, > > Serguei. > > > > > > > > 2. Another workaround if you are going to subsequently pass that > > > resulting string to some other > > > function anyways is to preface that function with fn$. It also > > > supports expressions surrounded > > > in backticks. The function does not have to be cat. > > > > > > library(gsubfn) > > > fn$cat("pi = $pi\n") > > > ## pi = 3.14159265358979 > > > > > > On Sun, Dec 14, 2025 at 8:07 PM ivo welch <[email protected]> wrote: > > >> One of the more convenient syntax sugars of perl is the embedding of > > >> variables in strings, aka, `$s="I am $a";`. R has similar > functionality > > >> through library glue. Alas, the library does not have the operator > > >> flexibility to make it possible for glue to introduce a `g"I am {a}"` > . > > >> (One can define g("I am {a}") but that steals more of the function > > >> namespace.) Would be nice sugar for end users to have... > > >> > > >> [[alternative HTML version deleted]] > > >> > > >> ______________________________________________ > > >> [email protected] mailing list > > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > > > -- > > Serguei Sokol > > Ingenieur de recherche INRAE > > > > Cellule Mathématiques > > TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504 > > 135 Avenue de Rangueil > > 31077 Toulouse Cedex 04 > > > > tel: +33 5 61 55 98 49 > > email: [email protected] > > > https://www.toulouse-biotechnology-institute.fr/en/plateformes-plateaux/cellule-mathematiques/ > > > > ______________________________________________ > > [email protected] mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
