Permalink
Reply
On Saturday, 21 October 2023 at 06:57:30 UTC, Walter Bright wrote:
>On 10/20/2023 9:54 PM, Steven Schveighoffer wrote:
>I'm not sure I understand this. What is dec()?
From https://github.com/John-Colvin/YAIDIP :
"Consider for example using stream manipulators such as dec and hex for writeln by using an i-string:+"
void fun(int x) {
writeln(i"$dec$x in hexadecimal is 0x$hex$x.");
// Lowering: --->
// writeln(.object.imported!"core.interpolation".InterpolationHeader!("", "dec", "", "x", " in hexadecimal is 0x", "hex", "", "x", ".")(),
// "", dec, "", x, " in hexadecimal is 0x", hex, "", x, ".");
}
Oh I see now what you are looking at! This is just like C++ though.
std::cout << "value in hex: " << std::hex << 42
<< ", value in decimal: " << std::dec << 42 << std::endl;
dec is not a function that gets called on the value, it's a manipulator to set a flag that says "now do decimal numbers". It's no different for this example use case.
And:
"There is no need for defining, implementing, and memorizing a sui generis mini-language of encoded format specifiers"
I wasn't making false statements about that, either.
The false statement is not that these words exist in the proposal. It's that you have misinterpreted what these words are -- these things are USE CASES and not required for the proposal.
> > >mysql requires a string as the sql for the prepared statement. Basically, you pass a string with a different type of placeholder specifier "?". It does not accept "%s". This is not something I have any control over.
See my example. There's no reason it cannot be extended to replace the %s with whatever is needed.
Hence, requiring allocation and runtime parsing to build the string.
> >So naturally, since you only get a runtime format string from DIP1027, you need to create an equivalent runtime string to pass to the library. How can you do that without allocations?
The { } syntax.
No, the {} thing is a horrendous workaround. Nobody will use it, they'd just use the original, as this is just a large set of footguns that has no redeemable qualities.
Consider that for mysql there are no "format specifiers", the entire point for having the {} is negated because it should always be ?. You just did $foo and not ${?}foo? Sorry user, that's on you. It will compile and fail at runtime, or even worse it will succeed and do something completely unexpected. This is not good API design. Writing incorrect code with this feature is super easy and will happen non-stop. Ironically, printf is going to be better because it has a magic compiler pragma to do the things that somehow the metaprogramming powerhouse of D could not handle.
But even if you needed an allocation, a malloc/free pair will suffice.
YAIDIP requires no allocations, even to build a format string.
>The problem with dec() is dec() returns an allocated string, so the free gets messy.
First, of course as previously mentioned, The C++ style stream manipulators are not a requirement of the DIP (or even proposed for the language). And second, as mentioned above, dec() does not allocate a string.
But even if you did rewrite it, it doesn't escape the template function, and can be RAII'd.
That is not comparable to building the correct string at compile-time. It also requires parsing the format string at runtime.
I'd agree that parsing it is a last resort if the { } also fails. But having implemented formatted writes, I can attest that parsing it is not a big deal. It's scanning till you see the %, then substitute your own version. Of course, using { } means the compiler does it for you at compile time.
Of course, we can all just switch to C or assembly, what is the big deal? The big deal is, I have a 21st century compiler, with insanely good metaprogramming capabilities. I shouldn't be parsing strings that the compiler built at compile time to give me substandard information. Give me the good stuff.
-Steve
