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