On 2/5/2020 1:15 AM, FeepingCreature wrote:
> On Wednesday, 5 February 2020 at 09:11:20 UTC, Walter Bright wrote:
>> On 2/4/2020 9:48 PM, FeepingCreature wrote:
>>> This may sound trivial, but trivial syntax enhancements matter, especially for a "top-ten" feature like format strings.
>>
>> It's a fair point, but there's a cost to supporting this. Nothing comes for free, and supporting everything is not practical.
> 
> Okay, what actually is the cost of lowering to a template instantiation returning a type with an alias to a tuple, compared to lowering directly to a tuple? Is this significantly harder to implement and support?

For one thing, it becomes part of the language specification. It has to be documented and taught. It turns a simple feature into a complex one. Having language semantics controlled by a hidden template is not in any other part of D. It implies that the behavior of interpolated strings is not predictable. Template instantiations are a LOT slower than direct implementation. Lots of interpolated strings means lots of template instantiations.

Yes, it's also significantly more code to implement, and there has to be error recovery for when the template can't be found, and checks for a rogue template.

All that has to be weighed against the benefit. Implementing something just because it is feasible and ticks a box is not a sufficient reason to do it. D must have smallish features that are widely useful, not be a large collection of trivia.

Am 05.02.20 um 23:30 schrieb Adam D. Ruppe:
> I'm not convinced that assigning to a string variable will actually be the most common usage though. You're surely creating this string to do something... and the variable doesn't actually do anything. You're surely going to pass it to a function eventually.. and often sooner rather than later.

A use case which I already had a few times already is templated strings for mixins.

I also just noticed that for this particular case, there is another problem. Usually for such strings, I would use the q{} syntax. As far as I understand, the current proposal does not allow mixing those 2. Is that correct? What would the syntax be anyways if we allow mixing those 2? iq{}?

Not being able to mix them would be very sad because this is the main use case where I have wished for string interpolation in the past.

On Thursday, 6 February 2020 at 07:43:38 UTC, Johannes Loher wrote:
> I also just noticed that for this particular case, there is another problem. Usually for such strings, I would use the q{} syntax. As far as I understand, the current proposal does not allow mixing those 2. Is that correct? What would the syntax be anyways if we allow mixing those 2? iq{}?

using implicit concatenation: auto s = i""q{$bananas};

On Thursday, 6 February 2020 at 07:43:38 UTC, Johannes Loher wrote:
> Am 05.02.20 um 23:30 schrieb Adam D. Ruppe:
>> I'm not convinced that assigning to a string variable will actually be the most common usage though. You're surely creating this string to do something... and the variable doesn't actually do anything. You're surely going to pass it to a function eventually.. and often sooner rather than later.
>
> A use case which I already had a few times already is templated strings for mixins.
>
> I also just noticed that for this particular case, there is another problem. Usually for such strings, I would use the q{} syntax. As far as I understand, the current proposal does not allow mixing those 2. Is that correct? What would the syntax be anyways if we allow mixing those 2? iq{}?
>
> Not being able to mix them would be very sad because this is the main use case where I have wished for string interpolation in the past.

I also have the same use-case but - if I remember correctly - it's been said in that thread that it could be implemented later once we already have an working interpolated-string implementation.

It is a reasonable answer to me.

On Thursday, 6 February 2020 at 07:00:33 UTC, Walter Bright wrote:
> sufficient reason to do it. D must have smallish features that are widely useful, not be a large collection of trivia.

The irony 😃

On Wednesday, 5 February 2020 at 22:30:14 UTC, Adam D. Ruppe wrote:

> Anything with an @attribute makes me "bleh". I'd really rather just have the explicit function to build a string. The explicit function is not a big hassle while being more friendly to several other uses.

I disagree. This will make it feel more like a real string. I'm sure there will be complains and confusion that for some strings `.idup` is required and for some it's not.

> I'm not convinced that assigning to a string variable will actually be the most common usage though. You're surely creating this string to do something... and the variable doesn't actually do anything. You're surely going to pass it to a function eventually.. and often sooner rather than later.

It's not the actual assignment that I referred to. It's the how it's formatted. I don't think the most common use case would be to call a function like `sql` or `jsx`. I think it would be to format the string as `std.format.format` would do. Then if you assigne the string to a variable or pass it to a function that expects a `string` is less interesting.

> I use `writefln` more often than `format`, for example. Most my cases of `"x" ~ to!string(y)` are in order to prepare a call to a function (actually most of those in my code are actually to make the `new Exception` argument - which I believe is bad code anyway, I'm just lazy af. I'd prolly just .idup an interpolated string there).

Yeah, exactly. But with my suggestion you would need the extra call to `.idup` and it would feel more like an actual string. Then that it goes through an extra struct will be an implementation detail in most case.

--
/Jacob Carlborg

On Thursday, 6 February 2020 at 07:00:33 UTC, Walter Bright wrote:
> On 2/5/2020 1:15 AM, FeepingCreature wrote:
>> On Wednesday, 5 February 2020 at 09:11:20 UTC, Walter Bright wrote:
>>> On 2/4/2020 9:48 PM, FeepingCreature wrote:
>>>> This may sound trivial, but trivial syntax enhancements matter, especially for a "top-ten" feature like format strings.
>>>
>>> It's a fair point, but there's a cost to supporting this. Nothing comes for free, and supporting everything is not practical.
>> 
>> Okay, what actually is the cost of lowering to a template instantiation returning a type with an alias to a tuple, compared to lowering directly to a tuple? Is this significantly harder to implement and support?
>
> For one thing, it becomes part of the language specification. It has to be documented and taught. It turns a simple feature into a complex one. Having language semantics controlled by a hidden template is not in any other part of D. It implies that the behavior of interpolated strings is not predictable. Template instantiations are a LOT slower than direct implementation. Lots of interpolated strings means lots of template instantiations.
>

Format strings force template instantiations anyways - even if you lower to a tuple. Consider the innards of format. Format strings *already* inescapably mean lots of template instantiations. One template instantiation on top of that isn't going to even move the needle. Furthermore, it actually improves the proposal by still allowing static type checking against format specifiers - which your tuple proposal does not allow, because the string is a runtime value. And yes, static format string checks cost templates, but this is something that everyone who works with format strings is already doing *anyways*. I'd rather D focuses its efforts on making templates fast rather than nursing a phobia against an integral, widely-used part of the language.

> Yes, it's also significantly more code to implement, and there has to be error recovery for when the template can't be found, and checks for a rogue template.

I don't understand the difficulty. Lookup should be module specific anyways? And I can't see error handling being more than a few lines to error out.

>
> All that has to be weighed against the benefit. Implementing something just because it is feasible and ticks a box is not a sufficient reason to do it. D must have smallish features that are widely useful, not be a large collection of trivia.

D must have features that work as intuitively expected. The tuple proposal fails this test. Simplicity in a feature is not worth confusing the feature's users, especially when a moderate increase in complexity buys an order of magnitude increase in usefulness.

On Thursday, 6 February 2020 at 12:30:20 UTC, FeepingCreature wrote:

>  I'd rather D focuses its efforts on making templates fast rather than nursing a phobia against an integral, widely-used part of the language.

+1000

> D must have features that work as intuitively expected. The tuple proposal fails this test. Simplicity in a feature is not worth confusing the feature's users, especially when a moderate increase in complexity buys an order of magnitude increase in usefulness.

+1000, and underline "as intuitively expected"

On Thursday, 6 February 2020 at 07:00:33 UTC, Walter Bright wrote:
> For one thing, it becomes part of the language specification. It has to be documented and taught. It turns a simple feature into a complex one. Having language semantics controlled by a hidden template is not in any other part of D. It implies that the behavior of interpolated strings is not predictable. Template instantiations are a LOT slower than direct implementation. Lots of interpolated strings means lots of template instantiations.
>
> Yes, it's also significantly more code to implement, and there has to be error recovery for when the template can't be found, and checks for a rogue template.
>
> All that has to be weighed against the benefit. Implementing something just because it is feasible and ticks a box is not a sufficient reason to do it. D must have smallish features that are widely useful, not be a large collection of trivia.

If you aren't going to allow this feature to have enough complexity to be worthwhile then I'd suggest you retract this DIP entirely. I work primarily in C# and I use interpolated strings all over the place because they Just Work and make string manipulation much easier to read. The implementation you've suggested here is the bare minimium to make string interpolation work in some cases for some things without any kind of protections for the user against accidentally (and silently!) breaking their code, and I would much rather not have string interpolation in D at all if the alternative is what is described in this DIP.

On Thursday, 6 February 2020 at 07:00:33 UTC, Walter Bright wrote:
> Template instantiations are a LOT slower than direct implementation. Lots of interpolated strings means lots of template instantiations.

For end users not familiar to D's new string interpolation solution. It could take a lot more time for them to figure out what just happened and to fix their code when something unexpected happened. This could be much more than the time to instantiate templates.

I know this try and error will happen, hopefully, only once to each user but every compile would take time to do the template stuff. But the time to make functions written in the future fo correctly handle the DIP's implementation is also needs to be considered.