Wanted: Format character for source code literal

Berni44 someone at somemail.com
Sat May 8 09:28:43 UTC 2021


On Friday, 7 May 2021 at 23:51:13 UTC, Q. Schroll wrote:
>> looking at the specifier (with the exception of `%s` which 
>> sometimes plays a special role).
>
> The role of `%s` is special, but not too special either. It 
> just gives a best effort result where other formats would just 
> fail.

That's not, what I meant. What I meant was, that some custom 
`toString` versions are only called, when `%s` is used (all, that 
do not take the format string or a `FormatSpec` as parameter).

> The task to return a string representation that can be 
> interpreted back is nothing to be delegated to a user-defined 
> routine.

Contrary, it's the only place where this can be done. The 
routines in `std.format` cannot know, what these objects need to 
be constructed. Maybe it is not even possible at all.

> _That,_ on the other hand, _is_ a problem. I don't know how big 
> that problem practically is because `real` cannot even be 
> formatted at CTFE

It can. I wrote that code. It's part of master since about two 
weeks.

> I guess the only sane result for floating point values is `%a` 
> with sufficient digits anyways

That's one reason, why I want to add `%D`: For floating point 
values I'd like to implement RYU (or something similar), which 
guarantees to emit a value, that produces exactly the same 
result, when read in.

> It's a breaking change fixing `%s` for floating point values in 
> the sense that the representation consists of enough decimals 
> to accurately represent the number.

And that's the reason, why I want to add `%D` and not to change 
`%s`.

> If `%(%s%)` does not give you proper char or string, I'd 
> consider it a bug.

Please define "proper char or string" first.

> I agree with you that a new format is necessary to achieve this 
> if done with a format character to begin with. I do question 
> whether format characters are the right approach. To me, this 
> looks more like a code generation tool than value formatting.

Sounds like you are thinking about a serialization tool or 
something like this. That's not what I plan. I think just about 
formatting values.

> The `%-(...%)` a hack, but it can be questioned whether 
> removing it is even worth the trouble.

If I were the only one to decide, I would remove it immediately, 
because in my eyes it is a bug. An yes, it's worth the trouble.

> It just breaks things.

That's why I haven't filed a PR yet. But I'm looking forward to a 
possibility to change this. And again here `%D` will help.

> The minus has otherwise no meaning for arrays.

It has: Left justification instead of right justification. It is 
just not/buggy implemented.

> It requires a single check: Is the `%` character followed by 
> `$`? The whole point of `%$` would be that it is not 
> customizable.

I want to have it customizable. For example I'd like to have 
output, that vertically aligns.

> I've been thinking about this a little. What is your goal?
> Maybe we're talking at cross purposes. I guess you want a 
> format specifier that formats any _built-in_ type in a way that 
> represents the object precisely. In a sense, you want a good 
> `%s` and not a not-really-the-best-effort `%s`.

Yes, that could be said so. I don't know the whole history of 
`%s`, but I think, its first meaning was "string" and this later 
was misunderstood to produce something, that is similar to a 
literal. This makes `%s` a mix. `%D` would take one of these 
meanings away from `%s`, giving it back its original meaning.

> My understanding was you want to represent objects as strings 
> in a way that can be used by the compiler to reconstruct the 
> object,

Well, that's what a source code literal is supposed to be, isn't 
it? But of course it is not limited to this use. People might use 
it to automatically generate asserts for unittests. Or to compare 
output of different runs, where you can be sure, that the 
differences are not due to rounding effects or such things, but 
real differences. Or whatever they want to do with it.

> Thinking about it, you can easily wrap objects in a struct and 
> make it do The Right Thing™. It doesn't complicate the `format` 
> implementation.

Of course there are always workarounds. With that argument you 
can question every function in phobos...


More information about the Digitalmars-d mailing list