On Thursday, 4 February 2021 at 18:14:59 UTC, Q. Schroll wrote:
> Formally, the compiler has to try the __interp and the string version. If both succeed (that's the relevant case) and instantiate THE SAME template, the string version (i.e. idup) will be used. Otherwise, the __interp is a better match and will be used.

I want to add how this works when using interpolated strings as template parameters. If templ is a template, templ!i"Hello ${name}, it's me!", also both rewrites are tried. If the only template is like this

    template templ(args...) { ... }

it will make args.length == 1 and args[0] == "Hello "~name~", it's me!". To match an interp sequence, one needs an overload like this

    template templ(args...)
        if (args.length > 0 && is(typeof(args[0]) == interp!str, string str))
    { ... }

that matches no string, but an interp object. The case is relevant because one might want to handle the parts specially even though @nogc and stuff is no concern for compile-time constructs.
The same as aforementioned, you cannot have one template that fits all and decides later.

On Thursday, 4 February 2021 at 16:45:14 UTC, Ola Fosheim Grøstad wrote:
> So if you write:
>
>   writeln(f`Four is {1+3}!`)
>
> The lookup will hit some templated construct f__interpolate__!….
>
>   writeln(f__interpolate__!`Four is {1+3}!`())
>
> Which has special capabilities that allows it to emit:
>
>   writeln(mixin(`tuple("Four is ", (1+3).to!string(), "!").expand`));
>
>
> D does not need more builtins, improve on pure meta programming instead seems more productive.

Agree, but we aren't there yet.

Personally, I would prefer f"$someVar" being rewritten to f!"$someVar" such that the whole logic, including custom parsing, can be implemented as a pure D function.
It requires however the access to the caller's context in order to seek for the missing parameters.
Moreover, further support from the frontend is needed such as throwing custom compiler errors and so on…

On Thursday, 4 February 2021 at 18:13:04 UTC, sighoya wrote:
> On Thursday, 4 February 2021 at 17:49:06 UTC, Imperatorn wrote:
>
>> @everyone:
>> We discuss more in depth on Discord. If you want to you could join the server and flesh out your ideas there. Easier to clarify various concepts imo.
>
> Which channel?

Mostly programming or dev_urandom

On Thursday, 4 February 2021 at 19:14:21 UTC, Imperatorn wrote:
> On Thursday, 4 February 2021 at 18:13:04 UTC, sighoya wrote:
>> On Thursday, 4 February 2021 at 17:49:06 UTC, Imperatorn wrote:
>>
>>> @everyone:
>>> We discuss more in depth on Discord. If you want to you could join the server and flesh out your ideas there. Easier to clarify various concepts imo.
>>
>> Which channel?
>
> Mostly programming or dev_urandom

Discord is external and cannot be Google searched. A DIP discussion should be archived for reference. How would I cite a Discord message in a DIP? How would I know it exists?

TL:DR: No.

On Thursday, 4 February 2021 at 17:05:30 UTC, Paul Backus wrote:
> This makes using interpolation to generate D code significantly more cumbersome, because '{' is a common character in D code, and every occurrence of it would have to be escaped. It is much easier if the sequence used to introduce an interpolated expression is not a valid D token.

Good! String mixins are evil, just a small step away from C-macros...
Their use should be discouraged and limited to the cases where the language falls short.

On Thursday, 4 February 2021 at 19:57:22 UTC, Q. Schroll wrote:
> On Thursday, 4 February 2021 at 19:14:21 UTC, Imperatorn wrote:
>> On Thursday, 4 February 2021 at 18:13:04 UTC, sighoya wrote:
>>> On Thursday, 4 February 2021 at 17:49:06 UTC, Imperatorn wrote:
>>>
>>>> @everyone:
>>>> We discuss more in depth on Discord. If you want to you could join the server and flesh out your ideas there. Easier to clarify various concepts imo.
>>>
>>> Which channel?
>>
>> Mostly programming or dev_urandom
>
> Discord is external and cannot be Google searched. A DIP discussion should be archived for reference. How would I cite a Discord message in a DIP? How would I know it exists?
>
> TL:DR: No.

You missed my @everyone. It was general information.

On Thursday, 4 February 2021 at 19:57:22 UTC, Q. Schroll wrote:
> On Thursday, 4 February 2021 at 19:14:21 UTC, Imperatorn wrote:
>> On Thursday, 4 February 2021 at 18:13:04 UTC, sighoya wrote:
>>> On Thursday, 4 February 2021 at 17:49:06 UTC, Imperatorn wrote:
>>>
>>>> @everyone:
>>>> We discuss more in depth on Discord. If you want to you could join the server and flesh out your ideas there. Easier to clarify various concepts imo.
>>>
>>> Which channel?
>>
>> Mostly programming or dev_urandom
>
> Discord is external and cannot be Google searched. A DIP discussion should be archived for reference. How would I cite a Discord message in a DIP? How would I know it exists?
>
> TL:DR: No.

DIP discussions are also just that. Most of the threads is just bikeshedding or dominated by single issues - regardless of where, having branching discussions of DIPs would be a good thing in the long run, a single forum thread is often not optimal as evidenced by the absolutely enormous DIP1036 thread.

If it's important it should go in the review thread.

And discord is easily searchable, easier than searching the forums.

On Thu, Feb 04, 2021 at 09:29:32PM +0000, Max Haughton via Digitalmars-d wrote: [...]
> And discord is easily searchable, easier than searching the forums.

Not IME.  Discord's linear UI (like Slack, phpBB, and many others of its ilk) is absolutely painful for searching, even more so for following long-winded discussions, whereas using a fully-threaded mail reader with the mail interface to the forums (or, for that matter, a full-fledged threaded NNTP client) that shows the threading structure of the discussion is *much* easier to follow.

It's a problem that has been solved since the ancient days of Usenet, but modern discussion platforms just keep reinventing the wheel poorly, or worse, not at all and ending up being completely useless.


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill

On 2/4/21 11:15 AM, Meta wrote:
> However, if you want a tuple sequence as described in the DIP, you can simply call a (probably compiler-supplied) helper method; maybe it doesn't even have to be new: why not .tupleof?

Wow, I can't believe I didn't think of this. This makes things a bit easier to reason about, because now we have a way to explicitly form a string and a way to explicitly form a tuple. I just tested, and "string".tupleof is an error, so that fits perfectly.

I have to confer with my partner in crime, but thank you for this nugget, and I really like the direction with the discussion here.

-Steve

On Thursday, 4 February 2021 at 22:34:37 UTC, Steven Schveighoffer wrote:
> On 2/4/21 11:15 AM, Meta wrote:
>> However, if you want a tuple sequence as described in the DIP, you can simply call a (probably compiler-supplied) helper method; maybe it doesn't even have to be new: why not .tupleof?
>
> Wow, I can't believe I didn't think of this. This makes things a bit easier to reason about, because now we have a way to explicitly form a string and a way to explicitly form a tuple. I just tested, and "string".tupleof is an error, so that fits perfectly.
>
> I have to confer with my partner in crime, but thank you for this nugget, and I really like the direction with the discussion here.
>
> -Steve

Glad you found it useful!