Interpolated strings

Nick Sabalausky (Abscissa) via Digitalmars-d digitalmars-d at puremagic.com
Thu Apr 20 18:23:09 PDT 2017


On 04/20/2017 04:43 PM, H. S. Teoh via Digitalmars-d wrote:
>
> But if you're printing lots of variables according to a precise template
> (e.g., rows of a table or a list of fields), format strings make more
> sense, e.g.:
>
> 	foreach (rec; records) {
> 		writefln("[%8d] %20s  %10.3f", rec.id, rec.name, rec.amount);
> 		writefln("      %20s  %10s", rec.altName, rec.comment);
> 		writefln("      %20s  %6s", rec.address, rec.postalCode);
> 	}
>

Meh, I'd argue that's just an example of why interpolated strings need 
support for formatting:

foreach (rec; records) {
     writeln(%"[%8{rec.id}] %20{rec.name   }  %10.3{rec.amount}");
     writeln(%"             %20{rec.altName}  %10{rec.comment}");
     writeln(%"             %20{rec.address}  %6{rec.postalCode}");
}


> And you can't beat this one with interpolated strings:
>
> 	auto matrix = [
> 		[ 1, 2, 3 ],
> 		[ 4, 5, 6 ],
> 		[ 7, 8, 9 ]
> 	];
> 	writefln("Matrix:\n%([ %(%3d, %) ]%|\n%)", matrix);
>

That's actually a perfect example of why I don't like printf-style 
formatting syntax. I've seen regexes that were more readable.


> If you're doing internationalization, though, neither option is a good
> one (I gave an example using dates in another post): printf-style
> formats have ordering issues (is it year first, then month, then day? Or
> month first then day then year? Which argument is which?), and

There's an extension to printf (which, IIRC, D's format supports) that 
allows reordering of arguments, much like C#'s format strings, by 
specifying the argument numerically. But it's an u-g-l-y syntax. Hard to 
remember, too. And why bother referring to the args numerically when you 
can have a format string that simply refers to them by name instead (ie, 
interpolated strings)?


> interpolated strings have the problem of exposing variable names to the
> translators (who are probably non-coders), potentially opening up the
> possibility of arbitrary code execution via l10n strings. In this case,
> it would seem best to have named arguments with format strings.

You're basically describing a templating engine: Which are essentially 
just interpolated strings with sandboxing (or alternatively, 
interpolated strings are just embedded templating engines).

And yes, I'd rather use a templating engine for non-coder translators 
than anything I've seen built-into any programming language: whether 
format string or interpolated string. But the last thing I'd hand them 
is anything with printf syntax.


> Between these textbook cases, though, is plenty of gray areas where it's
> debatable whether one syntax is clearly superior over the other(s). And
> here, factors of what you're used to, the kind of output you usually
> need to produce, etc., all come into play and there doesn't seem to be a
> clear one-size-fits-all.

When I see lots of options that are all basically the same thing, but 
each have their own little limitations and drawbacks (thus limiting each 
one's applicability to mere subsections of the overall problem 
domain)...well...that really bugs the shit out of me. ;) It's a big, 
loud, flashing sign that everybody's designs have gotten things wrong 
and none of them have quite hit the right mark.

It makes me want to consolidate: Break down the limitations that divide 
the current options, reach the true "core" of the problem, and show that 
they're not really all separate tools, but mere approximations of the 
proper generalization that simply needed to be found and brought out.

It's analogous to mathematical models: When the equations are complex 
and special-cased (like the rift between Newtonian physics and quantum 
physics) - that's how they know they probably got the model wrong. When 
they wind up with something simple, elegant and just-works, that's a 
sign they may be on the right track. Luckily, good general-purpose tools 
are a lot easier to come up with than unified field theory. ;) If 
scientists acted like programmers, the solar system model would still be 
stuck at the pre-Copernicus "All those planets have VERY COMPLEX 
movements! Very, VERY complex!! Good thing we have this big ol' toolbox 
with all the many, many tools involved in modeling all those 
complexities and special cases!"

Basically, I'm the antithesis of a polyglot programmer :)



More information about the Digitalmars-d mailing list