Wanted: Format character for source code literal

[Berni44]

On Wednesday, 5 May 2021 at 19:53:10 UTC, Q. Schroll wrote:
> I guess you thought primarily about the built-in types while I 
> primarily thought about user-defined types. I'm happy to 
> clarify.

Yes, thank you. That already helped a lot, although I fear, we 
still don't agree on most of the points with regard to the 
content... :-s

> The new `format` implementation could do three things when 
> encountering `%D` for formatting an object of a type with 
> custom formatting:

For me, this seems to be the wrong way to think about it. 
`format` doesn't encounter specifiers, but objects (in the wider 
sense). And in case of structs, classes and so on it delegates 
the handling of formatting to them, without even looking at the 
specifier (with the exception of `%s` which sometimes plays a 
special role). It's then up to that struct or class to define the 
meaning of `%D` for that specific struct or class.

> note that according to Walter, `bool` is an integer type

Yeah, but `std.format` handles them in a special 
`formatValueImpl`, that's why I treat them separately.

> Because `%D` for `bool`, integers ([...]), `floats`, arrays, 
> and AAs is nothing different from `%s`.

That's not true: bytes need a cast, longs a trailing 'L', like 
reals, floating point numbers are truncated with `%s` and don't 
provide the correct value and so on. There are a lot of subtle 
differences and that's why I think it would be a good thing to 
have this new format character.

> The only part where you'd need something different than `%s` is 
> characters, strings. That would be handy to have, I must admit. 
> You can mimic it using arrays tho

That was actually the starting point for me that led me to a 
desire for having `%D`: `%s` for arrays tries to mimic the 
intended result of `%D` (but fails at several places to do so 
correctly) and therefore treats characters and strings special. 
This led to the abuse of the `-`-flag (in `"%-(...%)`) which now 
causes a lot of problems. I thought long about how this could be 
fixed: With `%D` available, there would be a smoother transition 
be possible, because people using `%s` inside of `%(...%)` could 
just replace it with `%D` to get the current result and that 
eventually will make it possible to give `%s` (and the `-`-flag) 
its correct meaning back. (Of course this still needs deprecation 
cycles and maybe a preview switch or what else - it's still not 
easy.)

> And it's almost perfect! It works for character types, numeric 
> types, arrays, and AAs, too.

As I wrote above: That might look so at first sight, but it isn't 
the case.

> The `$` only has that meaning if it's preceded by a number. 
> `%`*N*`$`*…c* has a meaning for *N* a number and *c* a 
> character possibly preceded by other formatting stuff. But `%$` 
> is undefined in the sense that it is an error to use it.

But people will start to use it with width and other parameters 
and will report issues. Let along, that it will complicate the 
format spec parser significantly and thus might even introduce 
more bugs. I'm sorry, but with `%$` you'll opening the box of 
pandora.

> Now, let's talk about the implementation.

Sorry, but as long as we do not even agree on the goal, this is 
not useful.