On 2/25/20 1:54 AM, Walter Bright wrote:
> On 2/24/2020 2:45 PM, Steven Schveighoffer wrote:
>>> My inference of the discussion about this in the n.g. was the templates would be used so users could customize the behavior to be whatever they wanted.
>> By accepting a different type from string. In other words, an overload.
>> This means you can have code that treats an interpolated string differently than a string. Overloads based on literal types are not a new feature.
> 
> Were you proposing that an i"xxxx" be a different type? (DIP 1027 did not assign a type to it at all.)

No, I proposed that the first element of the tuple be specified as a new spec-defined type instead of a string.

I would love to have there be a way to specify that it's a specialized type that is akin to string literals. I'm not qualified to do that, and I'm not sure it's something we want to do (this WOULD be extra complicated and require some compiler magic).

I would note that it seems uncharacteristic for string enums to not be equivalent to string literals. If that were the case, this type WOULD be easy to set up effectively as a string literal.

Having the type detailed in the spec and implemented in the library is a "low cost" solution. Effectively, even though it doesn't need to be specified how this works, the compiler-library interaction is done via simple lowering, and the existing compiler has all the tools to implement the new type already.

> This would be radically different from DIP 1027, and a large increase in complexity (adding any new basic types is a big deal and a very intrusive change, and is tough to justify).

It's not a basic type in terms of a type defined by the compiler, but a type defined by the spec and implemented in the library (with existing language mechanisms). It's not intrusive at all, the changes to your proposed DIP are minimal, as it's still lowering.

> 
> This is different enough from DIP 1027 that it would merit a separate DIP.

Adam is working on this: https://github.com/dlang/DIPs/pull/186

> DIPs for the core language specify only behaviors, not implementations. Implementation possibilities can be included in an advisory manner only. Note that nowhere in the (massive and complicated) C++ core language specification is there any description of how the compiler should be implemented. Writing that an implementation must refer to specific templates implies that the behavior is customizable by the user via modifying those templates.

I understand, and I think we can reword the DIP proposal to reflect that.

-Steve

On 2/25/20 8:39 AM, Aliak wrote:
> On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:
>>> [...]
>>
>> Yes, that is the key impetus of our amendment, which I also wrote up on a gist weeks ago.... and it is now on github too! https://github.com/dlang/DIPs/pull/186
>>
>> [...]
> 
> I should’ve been more specific 😬 I was wondering if the same could be achieved without a introducing a new aggregate type!

I think there is not, unless you wanted to implement special rules in the compiler for string interpolations.

And that would be akin to overloading (something like "you have to tag a function as @acceptsinterpolation to have it work with interpolated strings"). Much simpler to just have a different type.

-Steve

On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote:
> I should’ve been more specific 😬 I was wondering if the same could be achieved without a introducing a new aggregate type!

Well, compiler magic, possibly with more @attributes. But that gets far messier than a simple struct, so we rejected it in the other thread.

I just added a section to my dip text explaining this though:

https://github.com/dlang/DIPs/pull/186/files#diff-2d3c5bf5c5d1f001279a15e3449b2338R325

basically once we address all the inevitable questions such a new thing would raise, we would essentially reinvent a struct with a new, awkward syntax anyway.

So my view is a struct is a simple, understandable, and proven solution.

On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote:
> On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:
>>> [...]
>>
>> Yes, that is the key impetus of our amendment, which I also wrote up on a gist weeks ago.... and it is now on github too! https://github.com/dlang/DIPs/pull/186
>>
>> [...]
>
> I should’ve been more specific 😬 I was wondering if the same could be achieved without a introducing a new aggregate type!

``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.

On 2/25/20 10:13 AM, Adam D. Ruppe wrote:
> On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote:
>> I should’ve been more specific 😬 I was wondering if the same could be achieved without a introducing a new aggregate type!
> 
> Well, compiler magic, possibly with more @attributes. But that gets far messier than a simple struct, so we rejected it in the other thread.
> 
> I just added a section to my dip text explaining this though:
> 
> https://github.com/dlang/DIPs/pull/186/files#diff-2d3c5bf5c5d1f001279a15e3449b2338R325 
> 
> 
> basically once we address all the inevitable questions such a new thing would raise, we would essentially reinvent a struct with a new, awkward syntax anyway.
> 
> So my view is a struct is a simple, understandable, and proven solution.

I think it's important that the compiler isn't involved with type construction, just lowering. It keeps things simple in the compiler.

-Steve

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.

Unless, of course, they modify druntime, but then, if they're going to do that, they could just as easily modify the meaning of various internal symbols in druntime that dmd refers to, like change _adEq2 to do something completely alien. But the expectation is that users generally would not do this.

Similarly, wrapping the interpolated tuple in a template is not customizable by the user. Rather, its sole purpose is to provide a distinct type from `string` that user can overload on, if they so wish.


T

-- 
The easy way is the wrong way, and the hard way is the stupid way. Pick one.

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.

On 2/25/2020 8:04 AM, Arine wrote:
> 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.

See what I mean about "no consensus emerging"? This thread amply illustrates that.

On 2/25/2020 7:04 AM, Steven Schveighoffer wrote:
> On 2/25/20 1:54 AM, Walter Bright wrote:
>> Were you proposing that an i"xxxx" be a different type? (DIP 1027 did not assign a type to it at all.)
> 
> No, I proposed that the first element of the tuple be specified as a new spec-defined type instead of a string. ... It's not a basic type in terms of a type defined by the compiler, but a type defined by the spec

I have no idea what this means. I'll wait until you and Adam come up with a finished DIP.

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.