October 21
On Saturday, 21 October 2023 at 17:27:01 UTC, Walter Bright wrote:
> On 10/21/2023 7:20 AM, jmh530 wrote:
>> I’m not really sure I grok the differences between the two proposals at the moment, but the people who support YAIDIP seem to think you have a lot of misconceptions and have left the door open for you to look at the implementations or play with it to have them corrected. If a bunch of people told me I was badly mistaken about something, I would want to find out why…
>
> I know why. YAIDIP is not an actual specification for it. When Adam and Steven prepare a specification then I will look at it again.
>
> (For example, Steven mentions a { } syntax, which does not exist in YADIP.)

So simply move the discussion on the implementation pull request of YAIDIP [1]: no misunderstanding about what can and can't do. It's the best way to grok it.

https://github.com/dlang/dmd/pull/15715

Discuss about the code, not about description of what the code is supposed to do.

/P




October 21

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.

> > >

https://www.digitalmars.com/d/archives/digitalmars/D/Just_another_example_of_missing_string_interpolation_370542.html#N370696

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

October 21
On Saturday, 21 October 2023 at 17:38:00 UTC, Paolo Invernizzi wrote:
> On Saturday, 21 October 2023 at 17:27:01 UTC, Walter Bright wrote:
>> On 10/21/2023 7:20 AM, jmh530 wrote:
>>> [...]
>>
>> I know why. YAIDIP is not an actual specification for it. When Adam and Steven prepare a specification then I will look at it again.
>>
>> (For example, Steven mentions a { } syntax, which does not exist in YADIP.)
>
> So simply move the discussion on the implementation pull request of YAIDIP [1]: no misunderstanding about what can and can't do. It's the best way to grok it.
>
> https://github.com/dlang/dmd/pull/15715
>
> Discuss about the code, not about description of what the code is supposed to do.
>
> /P

I think so too, or just provide a set of examples.

Like DIP x:
string s =<something>

DIP y:
string s = <something>

etc etc
October 21
On Saturday, 21 October 2023 at 09:00:54 UTC, Imperatorn wrote:
> Is there currently an implementation of 1027 that we can try?
Dunno if there is.

Still from DIP 1027 it is quite clear that you'd need to parse format string somehow. Now this parsing logic could be extracted and for example put in phobos, but then we'd stumble on another cons for DIP 1027:

3. Requires extra handling code of interpolation strings in phobos.

This Walter actually listed wrongly for YAIDIP, albeit for a different functionality, so I'd guess extra code for interpolation strings for DIP 1027 is also a no go, leaving us with original cons I've mentioned.


October 21

On Saturday, 21 October 2023 at 17:47:52 UTC, Steven Schveighoffer wrote:

>

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.

I think the misleading part of this example is that it uses writeln. Currently, writeln does not support passing this kind of "stream manipulator" as an argument--even if you write the lowered version out by hand, it will not work the way the example implies.

Probably the easiest fix is to replace writeln with a made-up function like stream.write.

1 2 3 4
Next ›   Last »