DIP 1027---String Interpolation---Format Assessment

Walter Bright newshound2 at digitalmars.com
Tue Feb 25 07:07:50 UTC 2020


On 2/24/2020 8:24 PM, FeepingCreature wrote:
> The behavior of formatting strings is *currently* 
> deferred to a template (std.format and co). This lets us do important decisions 
> at compiletime, like writing the format string to a file or a string buffer 
> piecewise without allocating memory. Why are you trying to get rid of this 
> flexibility?

std.format is a library function, with its behaviors entirely defined by the 
library. It is not a core language feature.

There's nothing stopping writing a CTFE-able function for doing formatting. It 
doesn't need to be built in to the compiler.


> As I understand it, the point of a format string template is to keep exactly 
> this kind of flexibility in exactly the same places it is currently available to 
> users, while simultaneously improving syntax legibility. To emphasize this 
> again: the @gc format string would have *reduced* flexibility for 90% of our 
> usecases (templated nogc/lowgc log library calls). As proposed, I don't see why 
> I would have ever used it.

Steven's proposal is radically different from #DIP1027. It should be separately 
proposed as a coherent DIP, not in bits and pieces over several n.g. postings.

All DIP1027 did was turn an istring into a tuple. That's it. The user can then 
do whatever they want with the tuple, including overloading a custom function 
based on the tuple arguments. DIP1027 did not actually do ANY formatting at all.


More information about the Digitalmars-d-announce mailing list