On 1/29/2021 7:22 AM, 12345swordy wrote:
> On Friday, 29 January 2021 at 04:21:24 UTC, Walter Bright wrote:
>> 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?
> 
> Prototype of the dip.

No, because it's not a question of can it work (presuming that the DIP was improved to more accurately specify it).

On 1/29/2021 9:18 AM, Steven Schveighoffer wrote:
> On 1/29/21 3:02 AM, 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.
> 
> It's doing what you want because it's possible. When someone says "yeah but I can't do this", and I say "OK, here's a wrapper I wrote in 15 minutes that does what you want" and you say "But that means I need a wrapper!", I don't really know where to go from here. You asked for something that works with printf, I gave it to you. If you don't like it, I don't know what to say, but it's trivially easy and can be inlined to a direct call.
> 
> What if I complained that @safe feature is unusable because I had to wrap the OS `read` as a @trusted function? Would that be a reasonable argument? It requires a simple wrapper, write it and be done. Or don't use @safe code.
> 
> In fact DIP1027 CANNOT make an overload for printf that's usable in D code, and the existing printf can't be used with strings (ironically the default specifier for DIP1027) without horrible syntax.
> 
> If you want to use printf without a wrapper, use printf as it was intended. If you want to use printf with interpolation strings, use a trivial wrapper.

It's simply that if I want to use it with printf, I have to write my own printf intermediary. That's not using it with printf. It's kinda trivially obvious that someone can write their own functions to do things, but pretending it is printf by naming it printf just puts a layer of confusion in for the reader. printf is so ubiquitous that it brings expectations when saying printf can be called that printf is actually being called, rather than some intermediary one must write oneself. Personally, I'd reject any PRs that contained an overload for printf or any other member of the C Standard Library.

The same applies to the mysql example in the DIP - the user has to write their own intermediary to get it to work.

Also, needing the GC for this to work with printf is a problem, as one cannot use it with betterC. Having this GC call hidden is not good, as D programmers calling printf are likely doing it because they want the low overhead and predictable behavior that printf provides. (I'm actually not sure if the GC would be required for the printf intermediary, which is another problem, as it isn't obvious when it is needed or not.)

On 1/29/2021 7:06 AM, Steven Schveighoffer wrote:
> The point of this is, we don't want to fit into printf-style formatting,

That is abundantly clear :-)

But it is a test on how powerful the feature is and where its limits are.


> DIP1027's syntax is designed to fit with a few existing functions.

More accurately, it is designed to fit with an enormous amount of existing use. The printf format pattern is very common with other functions - dmd's source code has many examples of it.

DIP1027 actually had zero knowledge of printf formatting other than %s being the default format, which is shared with writefln. This was very intentional in its design.


> It puts the burden on the user to make sure they understand how the rewrite will happen, and which functions to use to do this.

The rewrite is far simpler than #DIP1036's is, and no functions are used to do it. Note how short DIP1027 is.


> It is not forgiving of mistakes, which will compile and do the wrong thing.

Since D now does printf format checking, format mistakes will no longer compile. (We should have added that to D a decade ago! Dang I like that feature.)


> But I don't want to rehash DIP1027 here, that discussion has already happened.

Since #DIP1027 was rejected, it is necessary for #DIP1036 to be a substantial improvement over it, otherwise we just go sideways. Comparisons are fair.


> If you want to compare the two briefly, I would say DIP1027 designed for writef and format, nothing else. It can be used unintuitively with printf and other functions that have some similar parameter layouts. It can be used accidentally with many functions that happen to accept the parameters as arranged.

You and I strongly disagree on that assessment.


> DIP1036 is designed to be used by library writers to provide a mechanism to distinguish and handle properly interpolation strings ONLY when intended,

The fallback to matching string parameters doesn't fit that, and isn't different from DIP1027 in that regard.


> and do it with little effort, all while also providing the user a mechanism to seamlessly convert normal data into string data.

It pains me to say this, but would I use #DIP1036 in my own code? No. It adds too many layers of abstraction, is hard to document, hard to remember, adds special new rules for overloading, is unclear when it uses the GC, I have to write wrappers to use it, and the user-facing part just doesn't look good.

DIP1027 was a simple lexical rewrite - easy to remember, easy to document, sensible defaults, no allocations, no function calls, no overloading, no wrappers. It wasn't perfect, but simplicity and predictability are huge advantages.

P.S. I used to write macros in C named "printf" that would muck about with the arguments, add some logic, then call the real printf. After a few years I got tired of them, and put them in a bag with some rocks and threw it in the swamp.

On Sunday, 31 January 2021 at 05:37:09 UTC, Walter Bright wrote:
> On 1/29/2021 9:18 AM, Steven Schveighoffer wrote:
>
> It's simply that if I want to use it with printf, I have to write my own printf intermediary. That's not using it with printf. It's kinda trivially obvious that someone can write their own functions to do things, but pretending it is printf by naming it printf just puts a layer of confusion in for the reader. printf is so ubiquitous that it brings expectations when saying printf can be called that printf is actually being called, rather than some intermediary one must write oneself. Personally, I'd reject any PRs that contained an overload for printf or any other member of the C Standard Library.

Why is "working with printf" so important? I mean all the current code that uses printf can just carry on using it. Anyone who wants to use string interpolation can just start using iprintf from the d stdlib or whatever.

I mean i dont see why string interpolation working with printf is so important that it should put such constraints on the more modern aspects of D. It's a legacy C function, let it be that.

On Sunday, 31 January 2021 at 05:37:09 UTC, Walter Bright wrote:
> Also, needing the GC for this to work with printf is a problem, as one cannot use it with betterC.

This DIP does not require the GC to work with printf.

The little forwarding function Steven demonstrated is 100% compatible with betterC.

On Saturday, 30 January 2021 at 02:57:59 UTC, Steven Schveighoffer wrote:
> FYI, I was just made aware that this is because the message in the feedback thread is about to be deleted. I'm posting my reply the same as it was in there.
>
> [...]

In light of the criticism from various people, is there some kind of "middle ground" solution that could be made? 🤔

Like for example printf and friends, could the DIP somehow either have some helpers and/or show clear examples on how you would use interpolation in those cases?

Btw, I want this to pass, so I'm just trying to find a way forward.

On Sunday, 31 January 2021 at 12:24:30 UTC, Imperatorn wrote:
> On Saturday, 30 January 2021 at 02:57:59 UTC, Steven Schveighoffer wrote:
>> FYI, I was just made aware that this is because the message in the feedback thread is about to be deleted. I'm posting my reply the same as it was in there.
>>
>> [...]
>
> In light of the criticism from various people, is there some kind of "middle ground" solution that could be made? 🤔

DIP 1036 *is* the middle-ground solution. That's why it's such a mess.

The fact is, there's no broad consensus in the D community about how string interpolation ought to work. So no matter what solution you come up with, somebody is going to be disappointed with it.

On Sunday, 31 January 2021 at 12:59:27 UTC, Paul Backus wrote:
> On Sunday, 31 January 2021 at 12:24:30 UTC, Imperatorn wrote:
>> On Saturday, 30 January 2021 at 02:57:59 UTC, Steven Schveighoffer wrote:
>>> FYI, I was just made aware that this is because the message in the feedback thread is about to be deleted. I'm posting my reply the same as it was in there.
>>>
>>> [...]
>>
>> In light of the criticism from various people, is there some kind of "middle ground" solution that could be made? 🤔
>
> DIP 1036 *is* the middle-ground solution. That's why it's such a mess.
>
> The fact is, there's no broad consensus in the D community about how string interpolation ought to work. So no matter what solution you come up with, somebody is going to be disappointed with it.

If that's the case we can just proceed, because a solution with 100% approval will never exist.

On Sunday, 31 January 2021 at 13:17:21 UTC, Imperatorn wrote:
> because a solution with 100% approval will never exist.

Which is exactly why I fear string interpolation is never going to be accepted in the first place.

On Sunday, 31 January 2021 at 12:59:27 UTC, Paul Backus wrote:
> On Sunday, 31 January 2021 at 12:24:30 UTC, Imperatorn wrote:
>> On Saturday, 30 January 2021 at 02:57:59 UTC, Steven Schveighoffer wrote:
>>> FYI, I was just made aware that this is because the message in the feedback thread is about to be deleted. I'm posting my reply the same as it was in there.
>>>
>>> [...]
>>
>> In light of the criticism from various people, is there some kind of "middle ground" solution that could be made? 🤔
>
> DIP 1036 *is* the middle-ground solution. That's why it's such a mess.
>
> The fact is, there's no broad consensus in the D community about how string interpolation ought to work. So no matter what solution you come up with, somebody is going to be disappointed with it.

Try to please everybody and you end up pleasing nobody.