A t-string is a literal for a Template object which is a data holder, it doesn't actually do anything, so you would simply call

    bar(t"zoop")

This is exactly how Nim is. The f-string like equivalent uses a macro called "fmt" which has a short alias "&". So you can say:

    import std/strformat
    let world = "planet"
    echo &"hello {world}"

The regular expression module does a similar thing with a `re"regular expression"` syntax or std/pegs with peg"parsing expression grammar" and so on. There are probably numerous other examples.

In general, with user-defined operators and templates and macros, Nim has all kinds of Lisp-like facilities to extend the language, but with a more static focus which helps for both correctness and performance.

This was the original proposed idea in the PEP (750), but it changed overtime. There is a section in the PEP to explain why it changed to t-strings if you are interested.

True. Then you could use

  sql"..."
  html"..."

for each of the given examples and achieve some runtime type safety.

Use a function?

    bar(“zoop”)

It’s just syntax, like we used to have

    print “foo” 

that later became

    print(“foo”)

In my own language design (nothing public yet - need to prioritize more practical things at the moment) this is definitely on the menu. Aside from a minimal set, keywords are implemented as compile-time macros; and it's intended that they can be extended, both "natively" and in the implementation language, by writing AST-manipulation code. But the handling of arithmetic expressions, as well as the broader line/block structure, is hard-coded. (I draw inspiration from both Python and the Lisp family.)

meh, the difference between bar"zoop" and bar("zoop") isn't really big enough to be worth it.

I like F strings a lot, but for the most part I think all of the various X-strings should just be classes that take a string as an argument.