On Thursday, 12 December 2019 at 07:30:19 UTC, mipri wrote:
> A DIP that adds an innovative feature, or which enters
> poorly-explored design space, can be a conservative "80%
> solution" that has some caveats and limitations on its use,
> that people learning the language will need to learn to
> properly use the feature.

Yes, the requirement should be that it has been implemented as a library mixin and has been popular in usage for a long time.

Only then should new syntax be added for it.

On Thursday, 12 December 2019 at 07:30:19 UTC, mipri wrote:

> How about that? Undefined escape sequences are an error, so
> new ones can be added without breaking the language or changing
> the meaning of old code. And this no longer requires an ugly
> 'i' prefix.
>

That is a really good point! But, what about token strings?

mixin(q{
 auto ${functionName}() {
    return ${varName};
  }
});

On Thursday, 12 December 2019 at 05:07:44 UTC, Jonathan Marler wrote:
[...]
>
> I also don't see any mention of my proposal in the DIP in "Prior Work" or how this DIP compares to my proposal or Adam's.

I think this is really important, because ignoring their work in the DIP is not encouraging.
We all try to get the best solution and in speaking in general the DIP is taking care of a really useful feature I am missing.

When I saw the first examples in vibe.d templates using ruby like "#{}" , i thought it was a D language feature :-)

On Thursday, 12 December 2019 at 07:30:19 UTC, mipri wrote:
> A DIP that adds an innovative feature

This could be an innovative feature.

I see very little value in traditional string interpolation and I'd vote no on that. But these tuple ones are interesting and can do things unique to D... if we do it right.

> In code, this must all work:
>
>   auto s1 = i"I ate %apples and %{d}bananas.";

If that works, you've lost my support.

Note that with my proposal

string s1 = i"I ate %apples and %{d}bananas.";

could work though. auto and string are different - with string it can trigger `alias this`.

but if it is just plain string given from the compiler, we've gained nothing of interest. Even javascript's interpolation has more metaprogramming potential than that.

Do we want to lose to javascript?


BTW the JS one is actually quite interesting. It calls a user-defined function, passing the arguments - similar to the D tuple thing.

On Thursday, 12 December 2019 at 13:36:38 UTC, Adam D. Ruppe wrote:
> BTW the JS one is actually quite interesting. It calls a user-defined function, passing the arguments - similar to the D tuple thing.

Except you can actually assign it to a string?

On Thu, Dec 12, 2019 at 03:41:54PM +0000, aliak via Digitalmars-d wrote:
> On Thursday, 12 December 2019 at 13:36:38 UTC, Adam D. Ruppe wrote:
> > BTW the JS one is actually quite interesting. It calls a user-defined function, passing the arguments - similar to the D tuple thing.
> 
> Except you can actually assign it to a string?
[...]

As Adam already said, you can assign it to a string if the return type has alias this to string.


T

-- 
One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"

On Thursday, 12 December 2019 at 16:46:06 UTC, H. S. Teoh wrote:
> On Thu, Dec 12, 2019 at 03:41:54PM +0000, aliak via Digitalmars-d wrote:
>> On Thursday, 12 December 2019 at 13:36:38 UTC, Adam D. Ruppe wrote:
>> > BTW the JS one is actually quite interesting. It calls a user-defined function, passing the arguments - similar to the D tuple thing.
>> 
>> Except you can actually assign it to a string?
> [...]
>
> As Adam already said, you can assign it to a string if the return type has alias this to string.
>
>
> T

So i"blah %var" would not return a tuple but a type that has alias this to string? Like:

struct interolation_type {
  alias ?? this;
}

On Thursday, 12 December 2019 at 15:41:54 UTC, aliak wrote:
> Except you can actually assign it to a string?

The javascript version is allowed to return whatever it wants. The default one returns string but you can do other things with it too like return objects or functions or whatever.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

It passes the strings and the original elements, and you can actually even request the raw string to do custom escape sequences in it (really, the JS lexer treats it as a raw string, then there's a function on the object that can do default escape sequences for you).

If you wanna talk about taking the best ideas from other languages, Javascript's template literals are actually really nice. They are so much more than a multi-line string or a way to concatenate things.

This is why my proposal transforms the "interpolated string" into an object. Making it do the raw string with an escape method is a good idea to take too.

Anyway, the object can `alias toString this` so you assign it to string and it just works like newbies expect. Templates don't trigger alias this but do often use toString so that just works.

But then you can also recognize it specifically in functions/templates, store it in variables, etc for further processing. My interpolation object can be transformed into a ("%s", x) tuple. A plain tuple for calls like writeln. Or be passed to user functions.

XmlElement e = xml!i"
  <foo>#{bar}</foo>
";


There's a lot of cool things we can do.

On Thursday, 12 December 2019 at 17:01:01 UTC, Adam D. Ruppe wrote:
> On Thursday, 12 December 2019 at 15:41:54 UTC, aliak wrote:
>> [...]
>
> The javascript version is allowed to return whatever it wants. The default one returns string but you can do other things with it too like return objects or functions or whatever.
>
> [...]

It'd be great if you could expand on this with a list of examples of what D could do.

On Thursday, 12 December 2019 at 16:50:47 UTC, aliak wrote:
> So i"blah %var" would not return a tuple but a type that has alias this to string? Like:

Yup that's my proposal: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html

Walter's proposal isn't bad, though mine is better :)

However I would tweak one thing about mine. Before I said "auto arg1 = 50; ". I'd actually change that now to `auto arg1 = () => 50;` for more compile time / runtime mixing compatibility.

I might also steal the raw string thing from Javascript... and I actually kinda like the format string from Walter's proposal, though mine can actually do that too already by reading format stuff in CTFE right out of the string.