On Wednesday, 5 February 2020 at 06:07:21 UTC, Walter Bright wrote:
> The DIP is minimalist. This is intentional, as it proposes a very simple and straightforward rewrite of a literal into a tuple expression. Understanding tuple expressions (an existing D feature) is essential to understanding the DIP. This is a technique called "lowering" and is a great way of simplifying the semantics of a language and reducing corner cases and implementation bugs. Other examples:
>
> 1. the compiler rewrites 'while' loops into 'for' loops
>
> 2. the compiler rewrites RAII constructions into `try-finally` constructions
>
> In fact, the compiler could profit from doing a lot more lowering transformations.

I don't think the reason why people disagree with you is that they don't know what lowering is.

On Wednesday, 5 February 2020 at 06:07:21 UTC, Walter Bright wrote:
> To clarify:
>
> 1. the DIP is not specific to printf, writef, or SQL formats. It has no knowledge of any of them. It isn't even specific to calling a function. It simply produces a tuple expression, the first of which is a format string constructed from user-specified (not builtin) formats.
>
> The only exception is using %s if the user neglects to give a specification.

    float a;
    double b;
    real c;
    int d;

    printf(i"$a $b $c $d");

So the above translates to:

    printf("%s %s %s %s", a, b, c, d);

This DIP is worse than I thought... All this just so you can say it doesn't rely on a library implementation detail?


> 2. printf-aware checking can be added, but that would (and should) be an entirely orthogonal proposal, and would be effective with or without interpolated strings, as it has literally nothing to do with this DIP. A possible printf-format-checker would be run *after* the lowering to the tuple expression, and so would be equally effective for using or not using interpolated strings.

Because of 1, I have to *COMPLETELY* disagree. There's no way in hell this DIP should move forward without a checker if you plan with functionality of 1. You're going to force people to label specifiers themselves, when the compiler knows full well what type they are passing? That's just rediculous. No other language does this. The whole point is to keep it clean where you can. A float should have a %f not a %s inserted into the format.

> 3. having the interpolator escape % by writing %% means that % becomes "baked in" as a special character. This is a completely unnecessary complication.

It causes unexpected behavior. It wouldn't be that big of an issue if printf and friend's format was checked.

> 4. I repeat that I only use printf as an example because it is so well known and I don't have to spend a lot of time explaining what printf is and how it works. Note that writefln is also included as an example. There is nothing at all printf or writef specific in the design.

Other than it uses '%s' and uses a format string with args. Something multiple people here have said they don't want. It is purposefully designed the way it is because of printf and friends.

In the summarization of the DIP:

> the implementation must be compatible with BetterC, meaning printf and similar C functions

printf is a driving force behind the implementation. If you could ignore printf this would be implemented completely differently.

> 5. This proposal is not at all intended to be a substitute for knowing how printf formatting works. You're still going to have to remember to use %d for printing integers rather than %s or %g. This alone suggests that the DIP is not focused on printf.

This is just so backwards. Why. Why not just use printf without interpolated strings at this point.

This is what happens when someone that doesn't understand a feature and what benefits it brings tries to implement it. I'm sorry if that's harsh but it's the truth.

> ----
>
> The DIP is minimalist. This is intentional, as it proposes a very simple and straightforward rewrite of a literal into a tuple expression. Understanding tuple expressions (an existing D feature) is essential to understanding the DIP. This is a technique called "lowering" and is a great way of simplifying the semantics of a language and reducing corner cases and implementation bugs. Other examples:
>
> 1. the compiler rewrites 'while' loops into 'for' loops
>
> 2. the compiler rewrites RAII constructions into `try-finally` constructions
>
> In fact, the compiler could profit from doing a lot more lowering transformations.

The user doesn't have to interact with any of those. The user does have to interact with the result of an interpolated string as defined in this DIP. It isn't hidden from them.

    string v = i"value = $value";

A user isn't going to expect that to be:

    string v = ("value = %s", value);

You are lowering it for one minor use case where it is convenient , and then causing ugly behavior everywhere else. Not to mention it doesn't even do it properly, cause if you want to use a float you have to manually put %f yourself.

On 2/4/2020 10:12 PM, FeepingCreature wrote:
> I don't think the reason why people disagree with you is that they don't know what lowering is.

I've run into many who did not.

On 2/4/2020 10:48 PM, Arine wrote:
>      float a;
>      double b;
>      real c;
>      int d;
> 
>      printf(i"$a $b $c $d");
> 
> So the above translates to:
> 
>      printf("%s %s %s %s", a, b, c, d);

That's right.


> Because of 1, I have to *COMPLETELY* disagree. There's no way in hell this DIP should move forward without a checker if you plan with functionality of 1. You're going to force people to label specifiers themselves, when the compiler knows full well what type they are passing? That's just rediculous. No other language does this. The whole point is to keep it clean where you can. A float should have a %f not a %s inserted into the format.

The compiler actually cannot know that it is a printf format. For example, dmd is full of printf-like functions that are not called printf.


> You are lowering it for one minor use case where it is convenient , and then causing ugly behavior everywhere else. Not to mention it doesn't even do it properly, cause if you want to use a float you have to manually put %f yourself.

If you don't care for printf, that's why D has writef, where %s means "just make it work".


> This is what happens when someone that doesn't understand a feature and what
> benefits it brings tries to implement it. I'm sorry if that's harsh but it's
> the truth.

Berating other people in the forum is not permitted. Professional demeanor is expected.

On 05/02/2020 9:57 PM, Walter Bright wrote:
> On 2/4/2020 10:12 PM, FeepingCreature wrote:
>> I don't think the reason why people disagree with you is that they don't know what lowering is.
> 
> I've run into many who did not.

The people you are replying to are regulars of the D community and have been around for 10+ years.

They have learned from you.

When you explain your decisions in depth, people listen. They study the problem.

Every bodies priorities may be different, but that does not mean that their point is wrong or it is not backed up with the literature.

On 2/4/2020 9:48 PM, FeepingCreature wrote:
> This may sound trivial, but trivial syntax enhancements matter, especially for a "top-ten" feature like format strings.

It's a fair point, but there's a cost to supporting this. Nothing comes for free, and supporting everything is not practical.

On Wednesday, 5 February 2020 at 06:48:43 UTC, Arine wrote:
>
>     string v = i"value = $value";
>
> A user isn't going to expect that to be:
>
>     string v = ("value = %s", value);

This still boggles my mind. I know that you can simply write

string v = i"value = $value".format;

instead but this is not what anybody who already knows about string interpolation from any other language will expect. It is really weird to have a string syntax (i"") where the result of such an expression is not actually a string (or at the very least implicitly convertible to one).

Do we really want D to be the odd one out in this case?

On Wednesday, 5 February 2020 at 09:11:20 UTC, Walter Bright wrote:
> On 2/4/2020 9:48 PM, FeepingCreature wrote:
>> This may sound trivial, but trivial syntax enhancements matter, especially for a "top-ten" feature like format strings.
>
> It's a fair point, but there's a cost to supporting this. Nothing comes for free, and supporting everything is not practical.

Okay, what actually is the cost of lowering to a template instantiation returning a type with an alias to a tuple, compared to lowering directly to a tuple? Is this significantly harder to implement and support?

On Tuesday, 4 February 2020 at 22:38:59 UTC, Timon Gehr wrote:
> On 04.02.20 22:57, Steven Schveighoffer wrote:
>> On 2/4/20 8:44 AM, jmh530 wrote:
>>> On Tuesday, 4 February 2020 at 12:47:28 UTC, Steven Schveighoffer wrote:
>>>> [snip]
>>>>
>>>> As I expected, this was rejected, and Walter didn't understand what I was saying, says we shouldn't bake % into the format specification (it doesn't), and that it's like AST macros (it's not). Since there's no arguing on the feedback thread, I didn't want to push it.
>>>>
>>>
>>> Several people seem to think it is an important proposal, so I wouldn't want you to get discouraged.
>> 
>> I've been involved in many discussions like this with Walter, and it's not something I plan to do in this case. Once he makes up his mind, the chances that I can convince him otherwise shrink to almost non-existent, and it's not worth the effort IMO.
>> 
>>> However, when you say "Walter didn't understand what I was saying", another way to look at it is "I didn't communicate this well enough to convince Walter".
>> 
>> Possibly, but his response looks like he's trying to intentionally avoid discussing the proposal at all (most of the points were obviously incorrect, which leads me to believe that he would rather not discuss the actual proposal). I don't have lots of time to argue with people who aren't open to discussion.
>> 
>> -Steve
>
> +1. I have refrained from commenting on the string interpolation DIP so far because it is not important enough to me to yet again get into the situation that Steve, Adam, Jonathan,... are in now. It's a very frustrating way to lose a lot of what could have been productive time.
>
> Personally, I think it is ridiculous that the DIP focuses on printf over all other use cases so much yet in the common case, the proposed string interpolation will lead to access violations when used with printf in the most natural way, and it does not even support type safe formatting. This is not what people mean when they vote for string interpolation on a survey.
>
> @jmh530: Have you read all the arguments made? Do you really think they are not compelling enough to at least warrant being addressed?

The simple solution is just vote for not accepting the DIP ... personally, it will be my first DIP vote, and it will be against it.

String interpolation is not solving anything that needs to be solved, as a consequence, I don't want another 'convenient' feature added if it's not super-easy to grasp and use.

/P

On Wednesday, 5 February 2020 at 10:46:11 UTC, Paolo Invernizzi wrote:
> String interpolation is not solving anything that needs to be solved, as a consequence, I don't want another 'convenient' feature added if it's not super-easy to grasp and use.
>
> /P

I mean, define "needs to be solved"? Strictly speaking, once you have any Turing complete language, no language developed other is doing something that needs to be solved. What standard do you have for D feature development?

String interpolation is something that many people wish D had. (See the survey.) Why is that insufficient?