January 28, 2021
On Thursday, 28 January 2021 at 20:37:46 UTC, Kagamin wrote:
> Whoa, this looks impossible to lex.

It's not.

Please everyone, if you are going to leave a comment, leave a substantive explanation too.
January 28, 2021
On 1/28/2021 12:34 PM, 12345swordy wrote:
> That being said. Would it be easier to convince you to accept this if there is a prototype version of this?

Prototype of a way to call printf, or prototype of the DIP?

January 28, 2021
On 1/28/2021 6:42 AM, Steven Schveighoffer wrote:
> On 1/28/21 1:12 AM, Walter Bright wrote:
>> It appears to have abandoned being usable with printf?
> 
> Yes and no.
> 
> Yes, we do not think that using printf with interpolated strings *without modification* is an important goal. printf works fine as it is. This is D, not C. writeln IS usable without modifications.
> 
> And no, it is not abandoned, because it's perfectly possible because of the awesome power of metaprogramming allowed in this DIP:
> 
> https://run.dlang.io/is/X5HcXS

Interesting, but it's really writing your own printf, and one that doesn't accept any format modifiers.

January 29, 2021
On Friday, 29 January 2021 at 04:25:54 UTC, Walter Bright wrote:
> Interesting, but it's really writing your own printf, and one that doesn't accept any format modifiers.

It is trivial to accept format modifiers here too, his example just generated them from type info because you can.

It could just as well be

printf(i"%s${item} %02d${other_item}");

which expands to the inlinable call

printf("%s %02d", item, other_item);

by means of simple metaprogramming (you concat the strings at compile time - no runtime cost, it reduces to an eponymous template with an enum string - then build the call out of the remaining filtered tuple).

You can even do a CTFE scan of the string if you like and see that there's a % already and use it, or there isn't one and insert one.

While this is an overload to do the CTFE manipulations, they are indeed CTFE manipulations and thus have no runtime footprint; it reduces to an inlined call to the original thing. Same assembly.

D excels at these things.
January 29, 2021
Comparing two simple examples of #DIP1036 and #DIP1027:

DIP1036:
  printf(i"%s${item} %02d${other_item}"); // metaprogramming + printf overload

DIP2027:
  printf(i"$item ${%02d}other_item");  // direct


DIP1036:
  writeln(i"I ate ${apples} apples and ${bananas} bananas totaling ${apples + bananas} fruit.");

DIP1027:
  writefln(i"I ate $apples apples and $bananas bananas totaling $(apples + bananas) fruit.");


DIP1036 is more user typing, including awkward-to-type { }, along with needing substantial user code to implement (for printf).

DIP1027's syntax is optimized to make the most common cases the simplest for the user, no user code is required.
January 29, 2021
On 1/28/2021 8:47 PM, Adam D. Ruppe wrote:
> D excels at these things.

Ok, it's doable, but it's writing your own printf to do these manipulations.
January 29, 2021
On 29/01/2021 9:02 PM, Walter Bright wrote:
> On 1/28/2021 8:47 PM, Adam D. Ruppe wrote:
>> D excels at these things.
> 
> Ok, it's doable, but it's writing your own printf to do these manipulations.

I agree, we shouldn't need to write the mapper function which Steven wrote ourselves.

We (Steven and I) discussed this on Discord and left it at the function should not be included in the DIP. From a UX POV, it should be just a matter of doing an alias IMO. But that isn't really a goal of a DIP to specify such utility.
January 29, 2021
On 1/29/2021 12:46 AM, rikki cattermole wrote:
> I agree, we shouldn't need to write the mapper function which Steven wrote ourselves.
> 
> We (Steven and I) discussed this on Discord and left it at the function should not be included in the DIP. From a UX POV, it should be just a matter of doing an alias IMO. But that isn't really a goal of a DIP to specify such utility.

Even if it becomes part of Phobos, overloading C functions imported from external C libraries in general makes me uncomfortable, because it hides the fact that the C function isn't being called. I never liked C macros like:

    #define printf(...) printf("abc" ...)

for the same reason.
January 29, 2021
On Friday, 29 January 2021 at 08:57:13 UTC, Walter Bright wrote:
> On 1/29/2021 12:46 AM, rikki cattermole wrote:
>> I agree, we shouldn't need to write the mapper function which Steven wrote ourselves.
>> 
>> We (Steven and I) discussed this on Discord and left it at the function should not be included in the DIP. From a UX POV, it should be just a matter of doing an alias IMO. But that isn't really a goal of a DIP to specify such utility.
>
> Even if it becomes part of Phobos, overloading C functions imported from external C libraries in general makes me uncomfortable, because it hides the fact that the C function isn't being called. I never liked C macros like:
>
>     #define printf(...) printf("abc" ...)
>
> for the same reason.

Would a pragma i.e.

pragma(rewriteStringIntoFormatVarargs)
extern(C) int printf(const char* fmt, ...);

Make you feel more comfortable with this DIP?

This way only functions which the binding creator says fall into this style can be called via a interpolated string correctly. Without any overloads or anything else.
January 29, 2021
On 1/29/2021 1:15 AM, Rikki Cattermole wrote:
> Would a pragma i.e.
> 
> pragma(rewriteStringIntoFormatVarargs)
> extern(C) int printf(const char* fmt, ...);
> 
> Make you feel more comfortable with this DIP?
> 
> This way only functions which the binding creator says fall into this style can be called via a interpolated string correctly. Without any overloads or anything else.

The more special cases there are, the more unwieldy the language becomes, and the more unexpected interactions and unforeseen bugs.