On Wednesday, 26 February 2020 at 09:57:58 UTC, Walter Bright wrote:
> Requiring the compiler to use a specific template that is not specified by the user has no place in a language specification (and therefore no place in a proposed language change).

I think more naturally in D code rather than spec-ese (in other words, I find writing the implementation and usage examples to be a LOT easier than abstractly describing it), so it might help if you were to offer some specific suggestions.

Generally speaking, it'd be great if we could see you as a co-contributor rather than an obstacle.

On Wednesday, 26 February 2020 at 09:45:55 UTC, Walter Bright wrote:
> On 2/25/2020 1:36 AM, aliak wrote:
>> This may have already been answered in the other threads, but I was just wondering if anyone managed to propose a way to avoid this scenario with DIP1027?
>> 
>> void f(string s, int i = 0);
>> f(i"hello $a"); // silent unwanted bahviour.
>> 
>> ?
>
> It is lowered to:
>
>   f("hello %s", a);
>
> as designed. I don't know what's unwanted about it.

Wow. There were multiple examples in the review thread.


    void CreateWindow(string title, int w = -1, int h = -1);

    int a;
    CreateWindow(i"Title $a");


Yah, what's unwanted about that?

On Wednesday, 26 February 2020 at 10:36:34 UTC, aliak wrote:
> On Tuesday, 25 February 2020 at 16:04:59 UTC, Arine wrote:
>> ``How to distinguish a different type? Use a different type. No, is there another simpler way to do that instead?``
>>
>> Is this really the line of thinking going on here? It seems Walter has these arbitrary rules he's following which led up to the impractical and buggy solution that was DIP1027. Rules aren't meant to be followed blindly.
>
> Calm down. I didn't ask how to distinguish a type. I asked how to prevent a behaviour. There's a slight difference. If you misunderstood that then maybe I just didn't communicate that properly.

I was paraphrasing to make a point, hence the quotes. Maybe I should have been more explicit, you are trying to reinvent the wheel cause you are following a rule blindly, when there is an obvious simple and easy solution. Fyi, telling someone to calm down is about the worst thing you can do to make someone calm down.

On Wednesday, 26 February 2020 at 09:57:58 UTC, Walter Bright wrote:
> On 2/25/2020 9:44 AM, H. S. Teoh wrote:
>> On Mon, Feb 24, 2020 at 10:54:34PM -0800, Walter Bright via Digitalmars-d-announce wrote:
>> [...]
>>> Writing that an implementation must refer to specific templates
>>> implies that the behavior is customizable by the user via modifying
>>> those templates.
>> 
>> I think this is where the misunderstanding is. The proposed template is
>> defined by druntime, and is NOT customizable by the user.
>
> Requiring the compiler to use a specific template that is not specified by the user has no place in a language specification (and therefore no place in a proposed language change).
>
> The specification does NOT specify how it should be implemented.

That's just an implementation detail, the specification wouldn't require it. (This has been pointed out many times but you still seem to fall back on the same old argument after it's been debunked). It's how many D features already work and why druntime even exists. You're just arguing semantics at this point, not that it even matters. There's only one implementation of the D frontend + druntime. And the spec is in such a bad state, if someone wanted to create a new D compiler by simply following the spec, they wouldn't come out with anything that is remotely close to being compatible with today's D compilers.

On Wednesday, 26 February 2020 at 15:41:48 UTC, Arine wrote:
> Yah, what's unwanted about that?

To follow up on this, I expect a reply will be "the user ought to know how the feature works". This isn't a realistic expectation.

This is why I put in my little narrative in the new DIP, though it is deleted now since everyone else thought it was too anecdotal...

But as many of you know, I try to help D users pretty regularly, both existing D users with tricky questions and new D users who just aren't familiar with the language yet. I've answered about 1/5 of all stack overflow D questions myself, am often in the IRC channel to answer user questions, and read every post in the D.learn forum, again answering many myself.

So I see a lot of frequently asked questions and have developed a bit of a feel for where people common have trouble.

The #1 category of new or infrequent user difficulties is mismatched expectations coming from another language. A compile error is a chance to educate them as to D's difference, why it is that way, and how they can make it work for them. That's why I want a compile error on misuse. A type mismatch is the standard way we achieve this.

A quick run time error (e.g. null pointer segfault) results in users figuring it out on their own or asking us fairly quickly, but risks additional frustration since it is more delayed from the build.

But code that looks right to someone coming from another language yet silently doing weird stuff at runtime... I guarantee you would-be converts to D will find that really confusing and frustrating. Every single book or tutorial on D will have to call this out specifically. Every single usage example will have to point out the mismatched expectations.

Of course the spec will say it, but people often don't read the spec. (How many times have you seen people ask if D's `private` keyword is buggy?)

And a lot of new users will make the mistake anyway. We can prevent that with this simple, proven solution.

On Wednesday, 26 February 2020 at 16:08:53 UTC, Adam D. Ruppe wrote:
> On Wednesday, 26 February 2020 at 15:41:48 UTC, Arine wrote:
>> Yah, what's unwanted about that?
>
> To follow up on this, I expect a reply will be "the user ought to know how the feature works". This isn't a realistic expectation.

Yah I don't understand how he's fine on one hand introducing weird edge cases like this with String Interpolation. And then on the other hand he's removing brace initializers with a justification that it makes the language simpler and easier to learn. The examples given are obviously errors, and aren't the intended use for string interpolation. Rather than allowing errors to exist, it should just be made so that it doesn't happen.

You can also write:

    print(format(i"I have $apple_cnt apples"));

    void print(string s) { print_many(s); }

and get the behavior you're looking for.

On 2/26/2020 3:13 AM, Petar Kirov [ZombineDev] wrote:
> In all other languages with string interpolation that I'm familiar with, `a` is not passed to the `i` parameter.

All rely on a garbage collected string being generated as an intermediate variable.

On 2/26/2020 4:18 AM, FeepingCreature wrote:
> But to be thrice fair, Adam/Steven's proposal would work with the minor extension [...]

So would DIP1027.

On 2/26/2020 5:19 AM, Steven Schveighoffer wrote:
> We can do it without specifying that it's a template or the name of that template.

That isn't what was proposed. I seriously suggest preparing a DIP. Bits and pieces spread out over multiple posts and multiple threads is not working.


> But this statement still belies your misunderstanding. D is full of compiler-defined types that are implemented via templates in the library "not specified by the user".

None of them are specified/required by the spec. Again, the spec specifies the semantics. Not the implementation method. (This would address my issue with AST macros.)