On Thursday, 4 February 2021 at 20:46:15 UTC, Ola Fosheim Grøstad wrote:
> 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.

They are no where close to c-macros. What are you even talking about?

-Alex

On Thursday, 4 February 2021 at 21:06:49 UTC, Imperatorn wrote:
> On Thursday, 4 February 2021 at 19:57:22 UTC, Q. Schroll wrote:
>> 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.

@everyone: This is way off topic. Please keep the discussion focused on the contents of the DIP. Thank!

On Thursday, 4 February 2021 at 18:50:17 UTC, Adam D. Ruppe wrote:
> On Thursday, 4 February 2021 at 17:50:56 UTC, Meta wrote:
>> [...]
>
> It isn't "", it is i"". Javascript programmers seem to be able to figure out the concept that a different prefix may not yield a string. I'm sure D programmers can figure it out too.
>
> [...]

+1 for 1

On Thursday, 4 February 2021 at 15:24:56 UTC, Ola Fosheim Grøstad wrote:
>
> Python:
>
> f'{a} plus {b} is {a+b}'

Thanks for updating me :-)

On Thursday, 4 February 2021 at 16:15:03 UTC, 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?
>
> auto apples = 2;
> auto bananas = 3;
>
> auto s1 = i"I have ${apples + bananas} fruit";
> static assert(is(typeof(s1) == string));
>
> auto s2 = i"I have ${apples + bananas} fruit".tupleof;
>
> Then we can hide all the complexity of interpolated sequences behind the .tupleof (or whatever we decide on) magic property.

IMO, if I pass an i"I have ${apples + bananas} fruit" to a function, and it allocates memory, this feature completely misses its purpose and I can't see where I'd use it. Right now, we're using a *lot* of format calls of the form `template function!"format string"(arguments), and the fact that these calls are high-performance and don't involve the GC is a massive argument in their favor. In extreme cases we can end up pushing megabytes of data every second through functions like this. Demanding tupleof for every such call is such an awkward syntax that I'd honestly rather not use the feature at all.

To me the tuple form is the primary usecase, not the string form. I understand that people think developers want something simple first and foremost, but if the complex form is the *only form I'd be interested in using*, then something's wrong.

On 2/8/21 6:46 AM, FeepingCreature wrote:
> On Thursday, 4 February 2021 at 16:15:03 UTC, 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?
>>
>> auto apples = 2;
>> auto bananas = 3;
>>
>> auto s1 = i"I have ${apples + bananas} fruit";
>> static assert(is(typeof(s1) == string));
>>
>> auto s2 = i"I have ${apples + bananas} fruit".tupleof;
>>
>> Then we can hide all the complexity of interpolated sequences behind the .tupleof (or whatever we decide on) magic property.
> 
> IMO, if I pass an i"I have ${apples + bananas} fruit" to a function, and it allocates memory, this feature completely misses its purpose and I can't see where I'd use it. Right now, we're using a *lot* of format calls of the form `template function!"format string"(arguments), and the fact that these calls are high-performance and don't involve the GC is a massive argument in their favor. In extreme cases we can end up pushing megabytes of data every second through functions like this. Demanding tupleof for every such call is such an awkward syntax that I'd honestly rather not use the feature at all.

I would also not use a feature where .tupleof or some other syntax is needed to do what is needed (in major use cases). The goal here is to simplify syntax, we already have the comma-quote-spam form. However, I do like the mechanism of .tupleof for explicitly requesting the tuple form where it makes sense.

So an important part of this DIP that will NOT change is that you should be able to accept the tuple form via overload without having to tack on a converter or property.

> 
> To me the tuple form is the primary usecase, not the string form. I understand that people think developers want something simple first and foremost, but if the complex form is the *only form I'd be interested in using*, then something's wrong.

I think we can have both use cases, with overloads declaring somehow they accept the tuple form, and have it usable as a string form in other cases.

For sure, the primary use case for me is the tuple form. But there have been several users who are heavy users of the D language that have also declared that their primary use case is the string form (and in some cases have said they will NEVER use the tuple form).

If we don't have both available, the feature feels incomplete. My goal is to have both. And I think we can have both. I think this DIP as written covers both. The tricky part is, what is the *default* for functions that accept tuples but are not written to accept the tuple form. That is where a complete confusion would happen. And I am in agreement with people here that having the thing change forms when called on a variadic template, while workable, is not ideal.

So I think the next update, we will have a more definite mechanism to accept the tuple form without user intervention, and a more solid rule for when the idup rewrite happens.

This review is almost done, and it looks likely a 3rd review will have to happen if I make significant changes. But this is what these reviews are for. I'll post another thread when I put up the PR for the next changes and we can discuss there.

-Steve

On Monday, 8 February 2021 at 14:24:35 UTC, Steven Schveighoffer wrote:
> On 2/8/21 6:46 AM, FeepingCreature wrote:
>> 
>> IMO, if I pass an i"I have ${apples + bananas} fruit" to a function, and it allocates memory, this feature completely misses its purpose and I can't see where I'd use it.
>
> I would also not use a feature where .tupleof or some other syntax is needed to do what is needed (in major use cases). The goal here is to simplify syntax, we already have the comma-quote-spam form. However, I do like the mechanism of .tupleof for explicitly requesting the tuple form where it makes sense.
>
> So an important part of this DIP that will NOT change is that you should be able to accept the tuple form via overload without having to tack on a converter or property.
>

Thanks, that's a big relief! As long as the tuple form can be recognized by a template overload, I for one am completely satisfied.