www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - String Interpolation

reply Commander Zot <no no.no> writes:
can we please just have ```i"whatever ${var}"``` to return a 
fully interpolated string, not a tuple, not a template or 
anything.
because the common use case is ```auto s = i"whatever ${var}";```,
so maybe just lower it into ```format("whatever %s", var)```.

Then also introduce ```t"whatever ${var}"``` for a tuple/template 
returned object as a completely seperate proposal and you discuss 
whatever proposal is better for it YADIP or 1037 or whatever.

this way it's also a lot simpler to understand what is happening 
for the users.
Oct 21 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot wrote:

 can we please just have ```i"whatever ${var}"``` to return a 
 fully interpolated string


No. Please discontinue this thread, we've been over this a 
million times, no point doing it again.
Oct 21 2023
next sibling parent reply Commander Zot <no no.no> writes:
On Saturday, 21 October 2023 at 12:43:15 UTC, Adam D Ruppe wrote:

 On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot 
 wrote:

 can we please just have ```i"whatever ${var}"``` to return a 
 fully interpolated string


 No. Please discontinue this thread, we've been over this a 
 million times, no point doing it again.


you are missing the point. if ```i""``` does behave differently 
from just ```""``` this will lead to a huge number of people 
being confused later. they should really both be strings, or i"" 
should not exist at all. if you want interpolated tuples don't 
call it string interpolation and use t"" instead.
changing code from "" to i"" should not change it's behavior.
Oct 21 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 21 October 2023 at 15:42:37 UTC, Commander Zot wrote:

 On Saturday, 21 October 2023 at 12:43:15 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot 
 wrote:

 can we please just have ```i"whatever ${var}"``` to return a 
 fully interpolated string


 No. Please discontinue this thread, we've been over this a 
 million times, no point doing it again.


 you are missing the point. if ```i""``` does behave differently 
 from just ```""``` this will lead to a huge number of people 
 being confused later. they should really both be strings, or 
 i"" should not exist at all. if you want interpolated tuples 
 don't call it string interpolation and use t"" instead.
 changing code from "" to i"" should not change it's behavior.


Kinda agree that there could be multiple interpolation forms
Oct 21 2023
prev sibling parent reply Arafel <er.krali gmail.com> writes:
On 21/10/23 17:42, Commander Zot wrote:

 you are missing the point. if |i""| does behave differently from just 
 |""| this will lead to a huge number of people being confused later. 
 they should really both be strings, or i"" should not exist at all. if 
 you want interpolated tuples don't call it string interpolation and use 
 t"" instead. changing code from "" to i"" should not change it's behavior.


I also think that interpolated strings should behave like... well, 
strings. Anything else would break the principle of least astonishment, 
and it's not certainly what some people might expect, me among them. If 
you must do it, please just don't call it "interpolated **string**".


experience there), when you interpolate a string you get... well, a 
string. Only JS is more flexible here, but by default you'll get a string.

Even if they are not strings under the hood, they should be implicitly 
convertible to strings, at least in the default implementation, so if I 
have:

```
void foo(string s);
```

I should be able to do:

```
foo(i"Hello, $(name)");
```

or whatever other syntax is agreed upon, I don't really care that much 
about the bikeshedding.

Of course it's going to allocate when used like this, but it is a 
_convenience_ feature... The same way appending to a slice might 
allocate, those worried about allocations or using  nogc will have to 
take care of this, it's just syntactic sugar, after all.

Now, if under the hood there is something that library authors can 
override, that would be cool, but this "something" could just be a 
templated struct with an alias this to string. AFAIK the more specific 
match to the struct would then be the preferred overload.

I know `alias this` is kind of frowned upon, but I think this kind of 
usage is exactly what it is useful for:

```
void foo(string s) { }
void foo(IS)(IS s) if (isInterpolatedString!IS) { }
```

If a library author doesn't want a raw string and only support a 
specific interpolated string format, they just need to remove the first 
overload.
Oct 21 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 21 October 2023 at 16:30:07 UTC, Arafel wrote:

 On 21/10/23 17:42, Commander Zot wrote:

 [...]


 I also think that interpolated strings should behave like... 
 well, strings. Anything else would break the principle of least 
 astonishment, and it's not certainly what some people might 
 expect, me among them. If you must do it, please just don't 
 call it "interpolated **string**".

 [...]


Agreed
Oct 21 2023
prev sibling parent Bradley Chatha <sealabjaster gmail.com> writes:
On Saturday, 21 October 2023 at 16:30:07 UTC, Arafel wrote:

 I also think that interpolated strings should behave like... 
 well, strings. Anything else would break the principle of least 
 astonishment, and it's not certainly what some people might 
 expect, me among them. If you must do it, please just don't 
 call it "interpolated **string**".


Agreed. There were advocates for such a thing in the original set 
of discussions (including myself), but I can safely say that it's 
best to completely give up on such an idea.

There's a lack of desire to make language features rely on the 
GC. There also seems to now be regrets that D even has 
DRuntime(?), so adding any extra features or reliance on it is an 
instant no-go?

Regrettably, -betterC seems to now be the de-facto design pillar 
for this feature. While I do understand the arguments on why we 
can't just have `string a = i"1 + 1 = ${1 + 1}"` work and we have 
to be super special, quirky, and different, it just kinda sucks 
overall.
Oct 21 2023
prev sibling next sibling parent reply duckchess <duckchess chess.com> writes:
On Saturday, 21 October 2023 at 12:43:15 UTC, Adam D Ruppe wrote:

 On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot 
 wrote:

 can we please just have ```i"whatever ${var}"``` to return a 
 fully interpolated string


 No. Please discontinue this thread, we've been over this a 
 million times, no point doing it again.


can we just lower ```___""``` into ```mixin(___!"")```, where 
```___``` can be any template name. this way you can implement 
whatever interpolation method you want in a library.
Oct 21 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 21 October 2023 at 15:59:06 UTC, duckchess wrote:

 can we just lower ```___""``` into ```mixin(___!"")```, where 
 ```___``` can be any template name. this way you can implement 
 whatever interpolation method you want in a library.


https://github.com/adamdruppe/interpolation-examples/blob/master/01-basics.d

I'll add more examples to that repo as I have time, but this 
implementation allows libraries to do whatever methods they want.
Oct 21 2023
next sibling parent duckchess <duckchess chess.com> writes:
On Saturday, 21 October 2023 at 18:25:22 UTC, Adam D Ruppe wrote:

 On Saturday, 21 October 2023 at 15:59:06 UTC, duckchess wrote:

 can we just lower ```___""``` into ```mixin(___!"")```, where 
 ```___``` can be any template name. this way you can implement 
 whatever interpolation method you want in a library.


 https://github.com/adamdruppe/interpolation-examples/blob/master/01-basics.d

 I'll add more examples to that repo as I have time, but this 
 implementation allows libraries to do whatever methods they 
 want.


I understand your proposal, and YADIP is better than DIP1037 
imho. but it's adding a special case to the compiler and makes 
```string result = i"$name! See that DIP $dipNumber is easy to 
convert to string.".text;``` marginally better to write than what 
we can do today to have the exact same outcome ```string result = 
mixin(i!"$name! See that DIP $dipNumber is easy to convert to 
string.");``` where ```i``` would be a mixin template capturing 
the surrounding variables and returning an interpolated string.

if we just lower ```___""``` into ```mixin(___!"")```, we can 
write
```
import std.sinterp : i;
string s = i"$name! See that DIP $dipNumber is easy to convert to 
string.";
```

or

```
import std.sqlinterp : sql;
sqlstring s = sql"$name! See that DIP $dipNumber is easy to 
convert to string.";
```

and if there's no matching template, then we get a normal "i not 
found, did you forget to include std.sinterp?" error message.

there would be no need for the compiler to even know what string 
interpolation is. we'd have 'mixin strings'β„’.
Oct 21 2023
prev sibling parent reply duckchess <duckchess chess.com> writes:
On Saturday, 21 October 2023 at 18:25:22 UTC, Adam D Ruppe wrote:

 On Saturday, 21 October 2023 at 15:59:06 UTC, duckchess wrote:

 can we just lower ```___""``` into ```mixin(___!"")```, where 
 ```___``` can be any template name. this way you can implement 
 whatever interpolation method you want in a library.


 https://github.com/adamdruppe/interpolation-examples/blob/master/01-basics.d

 I'll add more examples to that repo as I have time, but this 
 implementation allows libraries to do whatever methods they 
 want.


here's a better example of what i suggest:

https://run.dlang.io/is/n121Ph
Oct 21 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 21 October 2023 at 20:58:44 UTC, duckchess wrote:

 On Saturday, 21 October 2023 at 18:25:22 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 15:59:06 UTC, duckchess wrote:

 can we just lower ```___""``` into ```mixin(___!"")```, where 
 ```___``` can be any template name. this way you can 
 implement whatever interpolation method you want in a library.


 https://github.com/adamdruppe/interpolation-examples/blob/master/01-basics.d

 I'll add more examples to that repo as I have time, but this 
 implementation allows libraries to do whatever methods they 
 want.


 here's a better example of what i suggest:

 https://run.dlang.io/is/n121Ph


Agreed. We need a better/simpler way to get the string from the 
expression without special syntax.

Like basically all other languages
Oct 21 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/21/2023 2:11 PM, Imperatorn wrote:

 Agreed. We need a better/simpler way to get the string from the expression 
 without special syntax.


```
import std.format;
alias f = std.format.format;

enum b = "betty";
pragma(msg, i"hello $b".f);
```
Oct 25 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 25 October 2023 at 07:08:06 UTC, Walter Bright 
wrote:

 On 10/21/2023 2:11 PM, Imperatorn wrote:

 Agreed. We need a better/simpler way to get the string from 
 the expression without special syntax.


 ```
 import std.format;
 alias f = std.format.format;

 enum b = "betty";
 pragma(msg, i"hello $b".f);
 ```


I get your point, however, it forces the user to import 
std.format in the entire codebase wherever a function takes or 
returns a string and the user wants to use string interpolation
Oct 25 2023
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, October 25, 2023 3:55:13 AM MDT Imperatorn via Digitalmars-d 
wrote:

 On Wednesday, 25 October 2023 at 07:08:06 UTC, Walter Bright

 wrote:

 On 10/21/2023 2:11 PM, Imperatorn wrote:

 Agreed. We need a better/simpler way to get the string from
 the expression without special syntax.


 ```
 import std.format;
 alias f = std.format.format;

 enum b = "betty";
 pragma(msg, i"hello $b".f);
 ```


 I get your point, however, it forces the user to import
 std.format in the entire codebase wherever a function takes or
 returns a string and the user wants to use string interpolation


That's what you have to do now anyway, and all string interpolation really
is is a way to do format with variable names thrown in the middle of the
string instead of %s.

- Jonathan M Davis
Oct 25 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 25 October 2023 at 11:40:15 UTC, Jonathan M Davis 
wrote:

 On Wednesday, October 25, 2023 3:55:13 AM MDT Imperatorn via 
 Digitalmars-d wrote:

 On Wednesday, 25 October 2023 at 07:08:06 UTC, Walter Bright





Yes, but wouldn't it be great to have the ability to do it like 
the other top 25 languages?


never have to think about imports, he happily just uses SI 
wherever he likes and achives a life of eternal happiness and 
joy. D *could* also provide that. Joy.

Here are the images emphasizing the joy and fulfillment brought 
about by successful string interpolation compared to the despair 
of failing to achieve it. Each image accentuates the significance 
of returning a string through string interpolation in bringing 
joy to life


On the left, a lively neighborhood with diverse residents of 
different genders and descents throwing a block party, dancing, 
and rejoicing. Screens showcase the magic of successful string 
interpolation. Bright lights and vivacious colors symbolize the 
joy of returning a string. On the right, a desolate town square 
with people of different genders and descents in despair, with 
gloomy colors and storm clouds, symbolizing the downfall from 
failed string interpolation.

Just look:
![Joy](https://i.ibb.co/Hx7QqrL/interp1.png)

It continues:

Left side: a vibrant outdoor celebration with diverse students of 
various genders and descents, laughing, collaborating, and 
showcasing projects that champion successful string 
interpolation. Festive decorations and lively music capture the 
essence of joy. Right side: a gloomy library with students of 
different genders and descents looking frustrated, surrounded by 
stacks of books and screens filled with error messages, 
representing the struggle without proper string interpolation.

Think about it
Oct 25 2023
prev sibling parent reply Hors <ho rs.com> writes:
On Saturday, 21 October 2023 at 12:43:15 UTC, Adam D Ruppe wrote:

 On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot 
 wrote:

 can we please just have ```i"whatever ${var}"``` to return a 
 fully interpolated string


 No. Please discontinue this thread, we've been over this a 
 million times, no point doing it again.


It's funny to see people defending interpolated strings shouldn't 
be string
Oct 27 2023
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 27 October 2023 at 14:19:01 UTC, Hors wrote:

 On Saturday, 21 October 2023 at 12:43:15 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot 
 wrote:

 can we please just have ```i"whatever ${var}"``` to return a 
 fully interpolated string


 No. Please discontinue this thread, we've been over this a 
 million times, no point doing it again.


 It's funny to see people defending interpolated strings 
 shouldn't be string


I didn't think this level of comedy existed, but it seems we have 
reached a new level of existence.

I tried giving this conversation to GPT but it said "I'm sorry, 
the content you provided is to surreal, it cannot be captured in 
this plane of reality"

That's cool!
Oct 27 2023
parent Arafel <er.krali gmail.com> writes:
On 27/10/23 16:38, Imperatorn wrote:

     It's funny to see people defending interpolated strings shouldn't be
     string
 
 I didn't think this level of comedy existed, but it seems we have 
 reached a new level of existence.
 
 I tried giving this conversation to GPT but it said "I'm sorry, the 
 content you provided is to surreal, it cannot be captured in this plane 
 of reality"
 
 That's cool!
 


As somebody who strongly supports making interpolated strings a drop-in 
replacement for strings, I think that, frustrating as it might feel, 
lowering the discourse doesn't help advance the argument.

It's better to show examples of where the feature as proposed would fall 
short of our, and I dare say most users', expectations.

 From my side, I think I've already presented my arguments multiple 
times, so I will try to no rehearse them any more.
Oct 27 2023
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 27 October 2023 at 14:19:01 UTC, Hors wrote:

 On Saturday, 21 October 2023 at 12:43:15 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot 
 wrote:

 can we please just have ```i"whatever ${var}"``` to return a 
 fully interpolated string


 No. Please discontinue this thread, we've been over this a 
 million times, no point doing it again.


 It's funny to see people defending interpolated strings 
 shouldn't be string


It's funny to see people thinking interpolated strings are 
strings when they are in fact program code.
Oct 30 2023
parent reply IGotD- <nise nise.com> writes:
On Monday, 30 October 2023 at 11:47:23 UTC, Patrick Schluter 
wrote:

 On Friday, 27 October 2023 at 14:19:01 UTC, Hors wrote:

 On Saturday, 21 October 2023 at 12:43:15 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot 
 wrote:

 can we please just have ```i"whatever ${var}"``` to return a 
 fully interpolated string


 No. Please discontinue this thread, we've been over this a 
 million times, no point doing it again.


 It's funny to see people defending interpolated strings 
 shouldn't be string


 It's funny to see people thinking interpolated strings are 
 strings when they are in fact program code.


I'm not sure if you are joking. Most people here understand that 
there is boilerplate code under interpolated strings. What many 
didn't like was the clumsy syntax in order to create a string 
from an interpolated string.

Nor having any form of implicit conversions in the language is a 
limitation.
Oct 30 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 12:54:05 UTC, IGotD- wrote:

 On Monday, 30 October 2023 at 11:47:23 UTC, Patrick Schluter 
 wrote:

 On Friday, 27 October 2023 at 14:19:01 UTC, Hors wrote:

 On Saturday, 21 October 2023 at 12:43:15 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot 
 wrote:

 can we please just have ```i"whatever ${var}"``` to return 
 a fully interpolated string











 I'm not sure if you are joking. Most people here understand 
 that there is boilerplate code under interpolated strings. What 
 many didn't like was the clumsy syntax in order to create a 
 string from an interpolated string.


It's close to Halloween, so I think it might be that!

I have proposed having both i and s, where s could to 
.text/.format for you basically.

It's reasonable, hygenic, expected and familiar. I don't have an 
issue with i"" not being a string, but it would be nice to also 
have s"" which would be a string.
Oct 30 2023
prev sibling next sibling parent reply duckchess <duckchess chess.com> writes:
On Monday, 30 October 2023 at 12:54:05 UTC, IGotD- wrote:

 On Monday, 30 October 2023 at 11:47:23 UTC, Patrick Schluter 
 wrote:

 On Friday, 27 October 2023 at 14:19:01 UTC, Hors wrote:

 On Saturday, 21 October 2023 at 12:43:15 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot 
 wrote:

 can we please just have ```i"whatever ${var}"``` to return 
 a fully interpolated string


 No. Please discontinue this thread, we've been over this a 
 million times, no point doing it again.


 It's funny to see people defending interpolated strings 
 shouldn't be string


 It's funny to see people thinking interpolated strings are 
 strings when they are in fact program code.


 I'm not sure if you are joking. Most people here understand 
 that there is boilerplate code under interpolated strings. What 
 many didn't like was the clumsy syntax in order to create a 
 string from an interpolated string.

 Nor having any form of implicit conversions in the language is 
 a limitation.


the problem only exist if we call them interpolated _strings_. 
just don't to that, it will avoid endless confusion. call them 
interpolation tuples in the language. or whatever. just avoid 
calling them _string_ at all costs.
Oct 30 2023
next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Monday, 30 October 2023 at 13:25:17 UTC, duckchess wrote:

 the problem only exist if we call them interpolated _strings_. 
 just don't to that, it will avoid endless confusion. call them 
 interpolation tuples in the language. or whatever. just avoid 
 calling them _string_ at all costs.


I had the same thought last week when we discussed this on IRC. 
First I thought _istring_ would be a good name, but then one can 
see "string" and think of it as some some kind of string, and 
after some time I started calling it _struple_ . :)
Oct 30 2023
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 30 October 2023 at 14:03:19 UTC, Dejan Lekic wrote:

 On Monday, 30 October 2023 at 13:25:17 UTC, duckchess wrote:

 the problem only exist if we call them interpolated _strings_. 
 just don't to that, it will avoid endless confusion. call them 
 interpolation tuples in the language. or whatever. just avoid 
 calling them _string_ at all costs.


 I had the same thought last week when we discussed this on IRC. 
 First I thought _istring_ would be a good name, but then one 
 can see "string" and think of it as some some kind of string, 
 and after some time I started calling it _struple_ . :)


+1 for struple
Oct 30 2023
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 14:03:19 UTC, Dejan Lekic wrote:

 On Monday, 30 October 2023 at 13:25:17 UTC, duckchess wrote:

 the problem only exist if we call them interpolated _strings_. 
 just don't to that, it will avoid endless confusion. call them 
 interpolation tuples in the language. or whatever. just avoid 
 calling them _string_ at all costs.


 I had the same thought last week when we discussed this on IRC. 
 First I thought _istring_ would be a good name, but then one 
 can see "string" and think of it as some some kind of string, 
 and after some time I started calling it _struple_ . :)


I kinda like it πŸ˜…

At least then you know it's not a string
Oct 30 2023
prev sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 30 October 2023 at 13:25:17 UTC, duckchess wrote:

 the problem only exist if we call them interpolated _strings_. 
 just don't to that, it will avoid endless confusion. call them 
 interpolation tuples in the language. or whatever. just avoid 
 calling them _string_ at all costs.


They are likely to be some other type under the hood in other 
languages as well, yet they called interpolated strings. Now, I 
suggest that go to the forums of all the languages that has 
interpolated strings and instruct them to stop using that term.
Oct 30 2023
parent reply duckchess <duckchess chess.com> writes:
On Monday, 30 October 2023 at 14:50:42 UTC, IGotD- wrote:

 On Monday, 30 October 2023 at 13:25:17 UTC, duckchess wrote:

 the problem only exist if we call them interpolated _strings_. 
 just don't to that, it will avoid endless confusion. call them 
 interpolation tuples in the language. or whatever. just avoid 
 calling them _string_ at all costs.


 They are likely to be some other type under the hood in other 
 languages as well, yet they called interpolated strings. Now, I 
 suggest that go to the forums of all the languages that has 
 interpolated strings and instruct them to stop using that term.


but they act or convert to string. which has it's own set of 
problems.
so either D gets 'string interpolation' that acts like a string 
too,
or D doesn't get 'string interpolation' but a completely 
different feature 'interpolation tuples' or however you wanna 
call it, that doesn't suggest to the user that the result is a 
string. you can still explicitly convert the result to a string 
in case you need that.
it's about not confusing the users.

and no, there's no need for other languages to change, as they 
have string interpolation. they don't have what the proposals for 
D are.
Oct 30 2023
parent reply bachmeier <no spam.net> writes:
On Monday, 30 October 2023 at 15:19:01 UTC, duckchess wrote:


 and no, there's no need for other languages to change, as they 
 have string interpolation. they don't have what the proposals 
 for D are.


It's more accurate to say that is that the only proposals that 
will get serious consideration are the ones that redefine the 
term "string interpolation". Certainly many around here have 
proposed that we have string interpolation in the usual sense of 
the term.
Oct 30 2023
parent duckchess <duckchess chess.com> writes:
On Monday, 30 October 2023 at 15:53:26 UTC, bachmeier wrote:

 On Monday, 30 October 2023 at 15:19:01 UTC, duckchess wrote:


 and no, there's no need for other languages to change, as they 
 have string interpolation. they don't have what the proposals 
 for D are.


 It's more accurate to say that is that the only proposals that 
 will get serious consideration are the ones that redefine the 
 term "string interpolation". Certainly many around here have 
 proposed that we have string interpolation in the usual sense 
 of the term.


you are not wrong. but at the same time there's good reason for 
it too.
the problem i have with built in string interpolation is, it's 
unflexible. that's why i'd rather see macros implemented in the 
language, but there's even more people against that, including 
walter.
but there's no way to have all options at once.

built in string interpolation:
  + simple syntax for strings.
  - unflexible for more than basic use cases.
macros:
  + super flexible.
  - has the problem macros have, like capturing everything.
adams proposal:
  + almost every use case is covered.
  + you can get an interpolated string with something like s!i"".
  - not what a normal user might expect, and slighly more verbose.
Walters DIP:
  - no flexible
  - super dangerous to use

that's why i wouldn't even use i"" as syntax, but t"" to make it 
extra clear that it'S not string interpolation like in other 
languages.
Oct 30 2023
prev sibling parent reply Arafel <er.krali gmail.com> writes:
On 30/10/23 13:54, IGotD- wrote:

 Nor having any form of implicit conversions in the language is a limitation.


Oh, but we do: it's called "alias this".

It would be totally possible to lower the interpolation to a struct with 
an `alias this` that points to a default `toString` method that would do 
basic concatenation.

If you think it will help you secure your code, you can have your 
function **only** accept the lowered struct. Otherwise, you can have a 
string overload in addition to / instead of that.

If you don't care where your string parameter comes from, you just act 
as usual, keep using strings, and let the users construct them however 
they prefer.

Now, the usual argument against this is that it ties the "low level" 
compiler to a "high level" feature like string formatting (for floats, 
for instance).

I understand the concern. However, most of the code is already there 
used in `pragma(msg, ...)` and in `static assert`, so at most it would 
need to add a call to `toString` (if present) for aggregated types.
Oct 30 2023
parent reply IGotD- <nise nise.com> writes:
On Monday, 30 October 2023 at 16:43:14 UTC, Arafel wrote:

 Oh, but we do: it's called "alias this".

 It would be totally possible to lower the interpolation to a 
 struct with an `alias this` that points to a default `toString` 
 method that would do basic concatenation.

 If you think it will help you secure your code, you can have 
 your function **only** accept the lowered struct. Otherwise, 
 you can have a string overload in addition to / instead of that.

 If you don't care where your string parameter comes from, you 
 just act as usual, keep using strings, and let the users 
 construct them however they prefer.

 Now, the usual argument against this is that it ties the "low 
 level" compiler to a "high level" feature like string 
 formatting (for floats, for instance).

 I understand the concern. However, most of the code is already 
 there used in `pragma(msg, ...)` and in `static assert`, so at 
 most it would need to add a call to `toString` (if present) for 
 aggregated types.


Thank you for this and alias this wasn't even on my mind. We need 
more posts like this, solutions and how to move forward. In 99% 
of the cases, you don't care what string interpolation is 
underneath and just want a string or parameter from it. The 
string interpolation implementation can even change over time.
Oct 30 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 30 October 2023 at 17:26:27 UTC, IGotD- wrote:

 Thank you for this and alias this wasn't even on my mind. We 
 need more posts like this, solutions and how to move forward.


This considered in my original proposal, 4 1/2 years ago:
http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html#my-string-interpolation-proposal
Oct 30 2023
parent Arafel <er.krali gmail.com> writes:
On 30/10/23 18:37, Adam D Ruppe wrote:

 On Monday, 30 October 2023 at 17:26:27 UTC, IGotD- wrote:

 Thank you for this and alias this wasn't even on my mind. We need more 
 posts like this, solutions and how to move forward.


 
 This considered in my original proposal, 4 1/2 years ago:
 http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html#my-string-interpolation-proposal


Yes, I think I read it at the time, and it probably has unconsciously 
shaped my ideas, as have DIP1036 and YAIDIP (these two consciously).

Anyway, I went ahead and implemented a proof of concept, using mixins:

https://gist.github.com/erkrali/d48ed754b68a26e326b61aad78d43ab7

There's no documentation, but the code and unit tests should be quite 
clear. In short:

```d
foo (string s) { }
formatedFoo(IS)(IS is) if (isInterpolatedString!IS) {
	// Advanced formatting here
}

auto message = mixin(i!`Hello, $(name). Your balance is 
$({%f1.3}balance).`);
foo(message); // Works
formatedFoo(message): // Also works
```

The formatting part is optional and ignored in the default `toString` 
implementation, but still made available for libraries. The original 
strings representing the interpolated expressions are also made available.

Pros:

* Intrinsic cast to string.
* Can get a tuple to be used in `text` (shorthand: `mixin(it!"Hello, 
$(name)");`.
* In the struct you get all the existing information: The "static" text, 
the format string, the original symbol, and the value to interpolate.
* Can do overloads that unlock more advanced processing.
* Functions can choose whether to support only the advanced processing.
* It should be possible to use in -betterC as long as `toString` is not 
called, i.e. as long as only the `struct` or the `tuple` are used.

Cons:

* Well, it's a mixin. But that's just to show how it could look like.
* It's tied to `std.conv : to` for the default string conversion.
* The parsing probably stinks, has bugs, and is inefficient as hell. It 
could also eat your kittens. I'd assume that a "proper" implementation 
would be much better, but I don't have that much experience (if any at 
all) in this area.

So, all in all, it's just a proof-of-concept to show that it can really 
be done, and it's not just theory.
Oct 30 2023
prev sibling next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
Doing so ties it to a specific formatting library.

Which isn't acceptable, we need to remove coupling between the language 
and druntime let alone Phobos. Its nothing but trouble coupling the 
language to a library especially for a language feature which doesn't 
need to be.
Oct 21 2023
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 21 October 2023 at 12:44:51 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 Doing so ties it to a specific formatting library.

 Which isn't acceptable, we need to remove coupling between the 
 language and druntime let alone Phobos. Its nothing but trouble 
 coupling the language to a library especially for a language 
 feature which doesn't need to be.


If the string conversion function is a template then there's no 
dependency unless it is actually needed. Allocating a string is a 
fundamental part of D. Wanting a string from an interpolated 
string is likely the most common case. Doing this must not 
require importing a function from anywhere, otherwise I might as 
well not use an interpreted string and save myself writing an 
import. So at minimum, the interpolated string must support a 
method suffix to request a string. That method can be a template 
so interpolated strings can still be used in  nogc, betterC, etc.
Oct 22 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 22 October 2023 at 20:21:54 UTC, Nick Treleaven wrote:

 Wanting a string from an interpolated string is likely the most 
 common case.


What's your evidence for this?
Oct 22 2023
parent reply Arafel <er.krali gmail.com> writes:
On 22/10/23 22:44, Adam D Ruppe wrote:

 What's your evidence for this?


There's obviously no scientific evidence, because I don't think anybody 
has researched the topic.

But as an example, and perhaps ironically, let me point you to none 
other than yourself (or at least something co-authored by yourself). 
 From 
[DIP1036](https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1036.md#description):


 The primary use case is to employ the literal in place of a 


string-yielding expression:

 ```d
 void foo(string s);

 foo(i"Hello, my name is ${name} and I am ${age} years old.");

 string s = i"${var1} + ${var2} = ${var1 + var2}";
 ```


Other than this, I would say that the fact that most (all?) languages 
that support string interpolation allow implicit conversion to string 
(or whatever other way of seamless replacing a string with an 
interpolated string) should be a really strong hint.

Is there even any counter-example, i.e. any language where an 
interpolated string cannot be used anywhere a regular string would be used?

Now, don't misunderstand me. I get that there are good reasons why it 
might not be desirable to have this behaviour in D. But then please just 
don't use a misleading name and syntax that will run opposite to most 
people's expectations, unless you want to keep explaining to new users that:

```d
string rs = r"This a string";
string qs = q"(This also is a string)";
//string is = i"This is an interpolated string, absolutely not a string";
```

And why you need to call `format` (DIP1027) / `text` (YAIDIP) in that case.
Oct 22 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Sunday, 22 October 2023 at 21:32:15 UTC, Arafel wrote:

 On 22/10/23 22:44, Adam D Ruppe wrote:

 What's your evidence for this?


 There's obviously no scientific evidence, because I don't think 
 anybody has researched the topic.

 But as an example, and perhaps ironically, let me point you to 
 none other than yourself (or at least something co-authored by 
 yourself). From 
 [DIP1036](https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1036.md#description):


 The primary use case is to employ the literal in place of a


 string-yielding expression:

 ```d
 void foo(string s);

 foo(i"Hello, my name is ${name} and I am ${age} years old.");

 string s = i"${var1} + ${var2} = ${var1 + var2}";
 ```




FWIW, that is something Adam opposed, but I insisted on. I did 
not think a String Interpolation DIP would be viable without it.

I still feel like one should be able to use an interpolation 
tuple as a string, but it's really hard to come up with a design 
that doesn't feel like a complete hack.

It's indeed much much simpler to just push that requirement to 
build a string if desired on the user.

-Steve
Oct 22 2023
next sibling parent reply duckchess <duckchess chess.com> writes:
On Sunday, 22 October 2023 at 21:55:23 UTC, Steven Schveighoffer 
wrote:

 On Sunday, 22 October 2023 at 21:32:15 UTC, Arafel wrote:

 On 22/10/23 22:44, Adam D Ruppe wrote:

 What's your evidence for this?


 There's obviously no scientific evidence, because I don't 
 think anybody has researched the topic.

 But as an example, and perhaps ironically, let me point you to 
 none other than yourself (or at least something co-authored by 
 yourself). From 
 [DIP1036](https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1036.md#description):


 The primary use case is to employ the literal in place of a


 string-yielding expression:

 ```d
 void foo(string s);

 foo(i"Hello, my name is ${name} and I am ${age} years old.");

 string s = i"${var1} + ${var2} = ${var1 + var2}";
 ```




 FWIW, that is something Adam opposed, but I insisted on. I did 
 not think a String Interpolation DIP would be viable without it.

 I still feel like one should be able to use an interpolation 
 tuple as a string, but it's really hard to come up with a 
 design that doesn't feel like a complete hack.

 It's indeed much much simpler to just push that requirement to 
 build a string if desired on the user.

 -Steve


or improve the language, so we can express what we want in a 
library.
something like this:
````
writeln(mixin("5, 7"));
```
and
````
mixin(string) nothing(string s)() { return s; }
writeln(nothing!"5, 7");
```

and i don't know if that would work either, but there should be 
_some_ way to make it possible to implement every form of 
interpolation exactly like YAIDIP or DIP1027 work completely in 
library code. bonus, this might be useful for other this too.
Oct 22 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 22 October 2023 at 22:57:30 UTC, duckchess wrote:

 or improve the language, so we can express what we want in a 
 library.


That's what the enhanced interpolation implementation does.

https://github.com/adamdruppe/interpolation-examples

Look down the examples here (and I have more coming as i find 
time to write them). How would you do them with your proposal?
Oct 22 2023
parent duckchess <duckchess chess.com> writes:
On Sunday, 22 October 2023 at 23:44:34 UTC, Adam D Ruppe wrote:

 On Sunday, 22 October 2023 at 22:57:30 UTC, duckchess wrote:

 or improve the language, so we can express what we want in a 
 library.


 That's what the enhanced interpolation implementation does.

 https://github.com/adamdruppe/interpolation-examples

 Look down the examples here (and I have more coming as i find 
 time to write them). How would you do them with your proposal?


```d
     /** make this work **/
     writefln(mixin(`InterpolationHeader!("", "greeting", ", ", 
"name", "", "exclamation", "")(), "", greeting, ", ", name, "", 
exclamation, ""`));

     /** so it becomes this **/
     writefln(InterpolationHeader!("", "greeting", ", ", "name", 
"", "exclamation", "")(), "", greeting, ", ", name, "", 
exclamation, "");

     /************************/

     /** then add smtn to D to automatically mix in strings at the 
call side **/
     mixin(string) t(string s)() {
         // todo: code that actually generates the return string
         return `InterpolationHeader!("", "greeting", ", ", 
"name", "", "exclamation", "")(), "", greeting, ", ", name, "", 
exclamation, ""`;
     }
     writefln(t!"$greeting, $name$exclamation");

     /** turns into **/
     writefln(mixin(`InterpolationHeader!("", "greeting", ", ", 
"name", "", "exclamation", "")(), "", greeting, ", ", name, "", 
exclamation, ""`));


     /************************/

     /** this is a sketch of how i'd like the default 
implementation for i to look **/
     mixin(string) i(string s)() {
         return q{(){
             struct RESULT {
             	string toString() const { return "....."}
                 mixin(string) printfargs(){ return ".....");
             	mixin(string) seq(){ return 
`InterpolationHeader!("", "greeting", ", ", "name", "", 
"exclamation", "")(), "", greeting, ", ", name, "", exclamation, 
""`;}
         	}
         	return RESULT();
     	}()}

     }
     writeln(i!"$greeting, $name$exclamation");
     writefln(i!"$greeting, $name$exclamation".seq);

```

again, idk if this specific idea works, but this is how i'd 
imagine usercode to look like


```d
writeln(i!"Hello, $name! I liked DIP $dipNumber a lot.");
string result = i!"$name! See that DIP $dipNumber is easy to 
convert to string.";
writefln(i!"$name has $$wealth:%0.2f".seq);
printf(i!"$name is $age years old.\n".printfargs);
writeln(tr!("I, $name, have a singular apple.", "I, $name, have 
%d apples.", count));
writeln(tr!("I, $name, have a singular apple.", "I, $name, have 
$count apples."));

```
Oct 22 2023
prev sibling parent Arafel <er.krali gmail.com> writes:
On 22/10/23 23:55, Steven Schveighoffer wrote:

 FWIW, that is something Adam opposed, but I insisted on. I did not think 
 a String Interpolation DIP would be viable without it.


That's why I mentioned that he was a co-author, I guessed something like 
that might have happened. Still, he was asking for evidence when he had 
put his name to that, so at the very least he should be aware that it's 
a very common view.

FWIW, I fully agree with you that the primary objective of string 
interpolation should be building strings. I've been trying to find 
references, and everything I found online just _assumes_ that this is 
the case.

Of course if you can **also** do something else with that it's even cooler.


 
 I still feel like one should be able to use an interpolation tuple as a 
 string, but it's really hard to come up with a design that doesn't feel 
 like a complete hack.


The problem is that it's inherently a high level feature. There's a 
reason why it first appeared and is even now still mostly used in 
interpreted languages.

Now, you want to embed it into the core of a language that tries to be 
minimalistic, so I understand that there are parts, for instance 
formatting numeric expressions, that doesn't really fit there.

But then you / the D leadership / the D Community should make a decision 
if we are to ever have this feature: either embed it into the language 
and bite the bullet, reusing for instance pragma msg's formatting 
routine, or extend the language so it can be implemented as a library.

I actually prefer the latter, and adding a shorthand for mixins might be 
a good solution, even if I also understand the preference for having 
mixins not too easy to use and clearly marked in the source code. Well, 
you can't have all, and as usual there are trade-offs.


 It's indeed much much simpler to just push that requirement to build a 
 string if desired on the user.


Also, you (Adam, Walter, even you) are usually arguing form a library 
writer's perspective.

On the other hand, me, as a user of other people's libraries, will often 
need to deal with places that I have no control over, and that only 
expect strings, or even C interfaces that want a char*.

Sure, I can use `text` all the time, but this kind of removes most of 
the usefulness of the feature.

So I think any such feature needs to be exclusively, or at least mostly, 
a caller thing.


 -Steve
Oct 23 2023
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/21/2023 5:38 AM, Commander Zot wrote:

 can we please just have ```i"whatever ${var}"``` to return a fully
interpolated 
 string, not a tuple, not a template or anything.
 because the common use case is ```auto s = i"whatever ${var}";```,
 so maybe just lower it into ```format("whatever %s", var)```.


Better tuple support is in the cards for D. They should be pretty
straightforward.

For DIP1027,

```
int var = 67;
auto s = format(i"whatever $var");
```
would be equivalent to:
```
auto s = "whatever 67";
```

I.e. there are two steps involved:

1. convert the istring to a tuple
2. convert the tuple to a string

Having them be two steps enables the user to insert step 2:

1. convert the istring to a tuple
2. modify the tuple
3. convert the tuple to a string
Oct 21 2023
parent reply Arafel <er.krali gmail.com> writes:
On 21/10/23 19:10, Walter Bright wrote:

 For DIP1027,
 
 |int var = 67; auto s = format(i"whatever $var"); |
 
 would be equivalent to:
 
 |auto s = "whatever 67";|


At which point it's barely an improvement overs what we can already do:

```
int var = 67; auto s = mixin(i!"whatever $var");
```

I'm not saving even one keypress, and readability isn't that much better 
either.

And we'll end up with multiple string literals, like `r"` and `q"`, and 
then something called "interpolated string" that uses a very similar 
token `i"` but that can't be used as a string, not even in the most 
straightforward cases.

Don't you think this will be unnecessarily confusing for users?

That's why I prefer DIP1036 over DIP1027, or even YAIDIP.

I understand that you don't want to make it implicitly convertible to 
strings. Fair enough, I'm sure there are solid reasons for that. But 
please, in that case, don't call it a "string", and also don't give it a 
string-like syntax.

Perhaps "interpolated sequence" with a clearly differentiated syntax? 
That would describe the feature much better.
Oct 22 2023
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 22 October 2023 at 11:32:12 UTC, Arafel wrote:

 On 21/10/23 19:10, Walter Bright wrote:

 For DIP1027,
 
 |int var = 67; auto s = format(i"whatever $var"); |
 
 would be equivalent to:
 
 |auto s = "whatever 67";|


 At which point it's barely an improvement overs what we can 
 already do:

 ```
 int var = 67; auto s = mixin(i!"whatever $var");
 ```

 I'm not saving even one keypress, and readability isn't that 
 much better either.

 And we'll end up with multiple string literals, like `r"` and 
 `q"`, and then something called "interpolated string" that uses 
 a very similar token `i"` but that can't be used as a string, 
 not even in the most straightforward cases.

 Don't you think this will be unnecessarily confusing for users?

 That's why I prefer DIP1036 over DIP1027, or even YAIDIP.

 I understand that you don't want to make it implicitly 
 convertible to strings. Fair enough, I'm sure there are solid 
 reasons for that. But please, in that case, don't call it a 
 "string", and also don't give it a string-like syntax.

 Perhaps "interpolated sequence" with a clearly differentiated 
 syntax? That would describe the feature much better.


Agreed, it's misleading. In almost all languages in existence it 
is implied that you want a string. It's about ergonomics. It 
should be clearly stated that you do *not* get a string and have 
to do that yourself, or more convenient ways should be added to 
do what you want in 99% of cases.
Oct 22 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Sunday, 22 October 2023 at 12:22:00 UTC, Imperatorn wrote:

 On Sunday, 22 October 2023 at 11:32:12 UTC, Arafel wrote:

 On 21/10/23 19:10, Walter Bright wrote:

 For DIP1027,
 
 |int var = 67; auto s = format(i"whatever $var"); |
 
 would be equivalent to:
 
 |auto s = "whatever 67";|


 At which point it's barely an improvement overs what we can 
 already do:

 ```
 int var = 67; auto s = mixin(i!"whatever $var");
 ```

 I'm not saving even one keypress, and readability isn't that 
 much better either.

 And we'll end up with multiple string literals, like `r"` and 
 `q"`, and then something called "interpolated string" that 
 uses a very similar token `i"` but that can't be used as a 
 string, not even in the most straightforward cases.

 Don't you think this will be unnecessarily confusing for users?

 That's why I prefer DIP1036 over DIP1027, or even YAIDIP.

 I understand that you don't want to make it implicitly 
 convertible to strings. Fair enough, I'm sure there are solid 
 reasons for that. But please, in that case, don't call it a 
 "string", and also don't give it a string-like syntax.

 Perhaps "interpolated sequence" with a clearly differentiated 
 syntax? That would describe the feature much better.


 Agreed, it's misleading. In almost all languages in existence 
 it is implied that you want a string. It's about ergonomics. It 
 should be clearly stated that you do *not* get a string and 
 have to do that yourself, or more convenient ways should be 
 added to do what you want in 99% of cases.


Buddy, not every language should be a Java-like language, stop 
expecting that your usecase should be enforced to everyone
Oct 22 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 22 October 2023 at 17:37:23 UTC, ryuukk_ wrote:

 On Sunday, 22 October 2023 at 12:22:00 UTC, Imperatorn wrote:

 On Sunday, 22 October 2023 at 11:32:12 UTC, Arafel wrote:

 On 21/10/23 19:10, Walter Bright wrote:







 Buddy, not every language should be a Java-like language, stop 
 expecting that your usecase should be enforced to everyone


Hey buddy, nice to hear you're doing fine
Oct 22 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/22/2023 4:32 AM, Arafel wrote:

 At which point it's barely an improvement overs what we can already do:
 
 ```
 int var = 67; auto s = mixin(i!"whatever $var");
 ```
 
 I'm not saving even one keypress, and readability isn't that much better
either.


If you can make `i` work as a template, why not? I encourage you to give it a 
try and write the template!

I've already worked out the logic for this:

https://github.com/dlang/dmd/pull/15722/files#diff-a556a8e6917dd4042f541bdb19673f96940149ec3d416b0156af4d0e4cc5e4bdR14291

Feel free to turn it into a template, and let's see.
Oct 22 2023
parent reply Arafel <er.krali gmail.com> writes:
On 23/10/23 3:13, Walter Bright wrote:

 On 10/22/2023 4:32 AM, Arafel wrote:

 At which point it's barely an improvement overs what we can already do:

 ```
 int var = 67; auto s = mixin(i!"whatever $var");
 ```

 I'm not saving even one keypress, and readability isn't that much 
 better either.


 
 If you can make `i` work as a template, why not? I encourage you to give 
 it a try and write the template!
 
 I've already worked out the logic for this:
 
 https://github.com/dlang/dmd/pull/15722/files#diff-a556a8e6917dd4042f541bdb19673f96940149ec3d416b0156af4d0e4cc5e4bdR14291
 
 Feel free to turn it into a template, and let's see.


First of all, there are already dub projects that do this [1,2] for the 
simple case that I mentioned of getting a string as end result.

But if you want the same flexibility that your DIP offers, here is a 
small proof of concept of how you can get a tuple to be used in an "-f-" 
function with a mixin:

```d
import std;

enum i(string T) = "imported!\"std.meta\".AliasSeq!(\"%s: %s\",\"" ~ T ~ 
"\"," ~ T ~ ")";

void main() {
     int var = 5;
     writefln(mixin(i!"var"));
     // var: 5
}
```

This is a just to show that it **can** be done.

Implementing advanced parsing logic that generates whatever AliasSeq you 
want based on the input string instead of hardcoding it assuming it's 
just a variable name shouldn't be conceptually hard, especially not if 
it already exists, just perhaps tedious.

[1]: https://code.dlang.org/packages/stri
[2]: https://code.dlang.org/packages/jdiutil
Oct 23 2023
next sibling parent reply Arafel <er.krali gmail.com> writes:
On 23/10/23 10:28, Arafel wrote:

 Implementing advanced parsing logic that generates whatever AliasSeq you 
 want based on the input string instead of hardcoding it assuming it's 
 just a variable name shouldn't be conceptually hard, especially not if 
 it already exists, just perhaps tedious.


Just a slightly more advanced version even with introspection and a 
dynamic format string... and even expressions!

Supporting expressions in aliases is a PITA, but it can be done with a 
bit of imagination. A delegate literal returning a voldemort struct 
would probably would work as well:

```d
enum i(string expr) =
     "new class(" ~ expr ~ ") {\n" ~
     "    alias _T = typeof(" ~ expr ~ ");\n" ~
     "    _T _v;\n" ~
     "        this(_T _v) {\n" ~
     "            this._v = _v;\n" ~
     "    }\n" ~
     "    static if (is(_T : int)) {\n" ~
     "        enum formatString =  \"%s (detected integer): %d\";\n" ~
     "    } else static if (is(_T : double)) {\n" ~
     "        enum formatString = \"%s (detected double): %f\";\n" ~
     "    } else {\n" ~
     "        enum formatString = \"%s (default: \" ~ _T.stringof ~ \"): 
%s\";\n" ~
     "    }\n" ~
     "    alias _seq =  imported!\"std.meta\".AliasSeq!(formatString,\"" 
~ expr ~ "\",_v);\n " ~
     "}._seq";

void main() {
     import std.stdio : writefln;
     import std.math : sqrt;

     int a = 5;

     writefln(mixin(i!"a + 10"));
     // a + 10 (detected integer): 15
     writefln(mixin(i!"sqrt(5.0) / 2"));
     // sqrt(5.0) / 2 (detected double): 1.118034
     string b = "5";
     writefln(mixin(i!"b"));
     // b (default: string): 5
}

```

https://run.dlang.io/is/hxxK0f

You can obviously do whatever you need with the input string.
Oct 23 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 23 October 2023 at 10:45:45 UTC, Arafel wrote:

 On 23/10/23 10:28, Arafel wrote:

 Implementing advanced parsing logic that generates whatever 
 AliasSeq you want based on the input string instead of 
 hardcoding it assuming it's just a variable name shouldn't be 
 conceptually hard, especially not if it already exists, just 
 perhaps tedious.




Just a quick comment. When posting code, be sure to check the 
"Enable Markdown" checkbox to the right of the send button.

If you did, your code would look like this:

```d
enum i(string expr) =
     "new class(" ~ expr ~ ") {\n" ~
     "    alias _T = typeof(" ~ expr ~ ");\n" ~
     "    _T _v;\n" ~
     "        this(_T _v) {\n" ~
     "            this._v = _v;\n" ~
     "    }\n" ~
     "    static if (is(_T : int)) {\n" ~
     "        enum formatString =  \"%s (detected integer): 
%d\";\n" ~
     "    } else static if (is(_T : double)) {\n" ~
     "        enum formatString = \"%s (detected double): %f\";\n" 
~
     "    } else {\n" ~
     "        enum formatString = \"%s (default: \" ~ _T.stringof 
~ \"): %s\";\n" ~
     "    }\n" ~
     "    alias _seq =  
imported!\"std.meta\".AliasSeq!(formatString,\"" ~ expr ~ 
"\",_v);\n " ~
     "}._seq";

void main() {
     import std.stdio : writefln;
     import std.math : sqrt;

     int a = 5;

     writefln(mixin(i!"a + 10"));
     // a + 10 (detected integer): 15
     writefln(mixin(i!"sqrt(5.0) / 2"));
     // sqrt(5.0) / 2 (detected double): 1.118034
     string b = "5";
     writefln(mixin(i!"b"));
     // b (default: string): 5
}
```
Oct 23 2023
parent reply Arafel <er.krali gmail.com> writes:
On 23/10/23 13:47, Imperatorn wrote:

 Just a quick comment. When posting code, be sure to check the "Enable 
 Markdown" checkbox to the right of the send button.


Unfortunately I use Thunderbird and the newsgroup, not the web 
interface, so I'm not sure how I can enable markdown there. If anybody 
knows (perhaps adding a header or something?) I would be glad to do it.

Alternatively, wouldn't it make sense to enable it by default so it 
would apply to all the messages coming from email / the newsgroup?
Oct 23 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 23 October 2023 at 12:03:04 UTC, Arafel wrote:

 On 23/10/23 13:47, Imperatorn wrote:

 Just a quick comment. When posting code, be sure to check the 
 "Enable Markdown" checkbox to the right of the send button.


 Unfortunately I use Thunderbird and the newsgroup, not the web 
 interface, so I'm not sure how I can enable markdown there. If 
 anybody knows (perhaps adding a header or something?) I would 
 be glad to do it.


Oh, I see.


 Alternatively, wouldn't it make sense to enable it by default 
 so it would apply to all the messages coming from email / the 
 newsgroup?


Fair point
Oct 23 2023
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Monday, 23 October 2023 at 12:03:04 UTC, Arafel wrote:

 On 23/10/23 13:47, Imperatorn wrote:

 Just a quick comment. When posting code, be sure to check the 
 "Enable Markdown" checkbox to the right of the send button.


 Unfortunately I use Thunderbird and the newsgroup, not the web 
 interface, so I'm not sure how I can enable markdown there. If 
 anybody knows (perhaps adding a header or something?) I would 
 be glad to do it.

 Alternatively, wouldn't it make sense to enable it by default 
 so it would apply to all the messages coming from email / the 
 newsgroup?


There isn't an easy way to do it. Vladimir wrote a gist that does 
it as a proxy server, which I used for a long time. But now with 
the new update, thunderbird is just completely borked for me, and 
I don't feel like rebuilding the data, so I'm using the web forum 
for now.

But in case you want to try it, it is here: 
https://gist.github.com/CyberShadow/ccb3813d5953e5e7f2c53fe43275f986

-Steve
Oct 23 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/23/2023 5:03 AM, Arafel wrote:

 Unfortunately I use Thunderbird and the newsgroup, not the web interface, so
I'm 
 not sure how I can enable markdown there. If anybody knows (perhaps adding a 
 header or something?) I would be glad to do it.



There's a thunderbird extension to do it. I use it. It's called "Render
Markdown 
Messages".
Oct 24 2023
parent reply Arafel <er.krali gmail.com> writes:
On 25/10/23 8:52, Walter Bright wrote:

 There's a thunderbird extension to do it. I use it. It's called "Render 
 Markdown Messages".


I also use it, but that's only for rendering... it stills sends the 
messages as plaintext, even if one uses markdown, so the markdown shows 
unprocessed in the web interface.

Those of us using the extension see them properly rendered, though :-)

Apparently there is a bug for thunderbird about that:

https://bugzilla.mozilla.org/show_bug.cgi?id=1280912

7 years and still no sign of a solution anytime soon...
Oct 25 2023
parent David Gileadi <gileadisNOSPM gmail.com> writes:
On 10/25/23 12:54 AM, Arafel wrote:

 On 25/10/23 8:52, Walter Bright wrote:

 There's a thunderbird extension to do it. I use it. It's called 
 "Render Markdown Messages".


 
 I also use it, but that's only for rendering... it stills sends the 
 messages as plaintext, even if one uses markdown, so the markdown shows 
 unprocessed in the web interface.
 
 Those of us using the extension see them properly rendered, though :-)
 
 Apparently there is a bug for thunderbird about that:
 
 https://bugzilla.mozilla.org/show_bug.cgi?id=1280912
 
 7 years and still no sign of a solution anytime soon...


There's also this bug by our Vladimir Panteleev:

https://bugzilla.mozilla.org/show_bug.cgi?id=1717221
Oct 25 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/23/2023 1:28 AM, Arafel wrote:

 ...


Thank you. The trouble is with the mixin. It can't be dispensed with.
Oct 24 2023
parent reply Arafel <er.krali gmail.com> writes:
On 25/10/23 8:49, Walter Bright wrote:

 Thank you. The trouble is with the mixin. It can't be dispensed with.


Well, I know you want to make mixins clearly identifiable, but I would 
suggest some easy sintax for string mixins generated by a template.

For instance, using `!!` (I think it's an unused token):

```d
foo!!(a, 42)
```

would be literally just another way of writing:

```d
mixin(foo!(a,42))
```

and thus anybody could implement:

```d
i!!"Helo ${name}"
```

as a library solution, or even use the existing ones.

You could create mixins that are tighly coupled to the called function, 
or generic ones... it would be the most flexible solution.
Oct 25 2023
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, October 25, 2023 2:00:38 AM MDT Arafel via Digitalmars-d wrote:

 On 25/10/23 8:49, Walter Bright wrote:

 Thank you. The trouble is with the mixin. It can't be dispensed with.


 Well, I know you want to make mixins clearly identifiable, but I would
 suggest some easy sintax for string mixins generated by a template.

 For instance, using `!!` (I think it's an unused token):

 ```d
 foo!!(a, 42)
 ```

 would be literally just another way of writing:

 ```d
 mixin(foo!(a,42))
 ```

 and thus anybody could implement:

 ```d
 i!!"Helo ${name}"
 ```

 as a library solution, or even use the existing ones.

 You could create mixins that are tighly coupled to the called function,
 or generic ones... it would be the most flexible solution.


IMHO, mixins should be explicit, obvious, and greppable, and adding a
separate syntax for them which tries to hide them is going to make the
language worse. However a string is generated, if the programmer wants to
turn it into code, they should just use mixin, and if it's ugly, it's ugly,
but at least it's clear what's going on.

- Jonathan M Davis
Oct 25 2023
next sibling parent reply Arafel <er.krali gmail.com> writes:
On 25/10/23 13:29, Jonathan M Davis wrote:

 IMHO, mixins should be explicit, obvious, and greppable, and adding a 
 separate syntax for them which tries to hide them is going to make the 
 language worse. However a string is generated, if the programmer wants 
 to turn it into code, they should just use mixin, and if it's ugly, it's 
 ugly, but at least it's clear what's going on.


I agree, however the current options regarding string interpolation seem 
to be suboptimal:

1. Get a string interpolation that doesn't get you strings, and that 
needs support from the called function (or only work in specific cases, 
not for `foo(string bar);`. You also can't assign to string, nor use it 
in most libraries that don't support it explicitly.

2. Use a library solution using string mixins (quite cumbersome as a 
user, and probably also inefficient).

3. Introduce high level dependencies in the language itself, at least to 
do the formatting.

So I was just trying to brainstorm alternatives that would allow a 
library solution.

The biggest hurdle is accessing to the caller's scope, so far only 
string mixins get that. There could be perhaps a different feature that 
does it, i.e. a way to define a (compile time) function that get access 
to the caller's scope, but I'm not sure we would actually want that.
Oct 25 2023
next sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Wednesday, 25 October 2023 at 15:05:52 UTC, Arafel wrote:

 On 25/10/23 13:29, Jonathan M Davis wrote:

 IMHO, mixins should be explicit, obvious, and greppable, and 
 adding a separate syntax for them which tries to hide them is 
 going to make the language worse. However a string is 
 generated, if the programmer wants to turn it into code, they 
 should just use mixin, and if it's ugly, it's ugly, but at 
 least it's clear what's going on.


 I agree, however the current options regarding string 
 interpolation seem to be suboptimal:

 1. Get a string interpolation that doesn't get you strings, and 
 that needs support from the called function (or only work in 
 specific cases, not for `foo(string bar);`. You also can't 
 assign to string, nor use it in most libraries that don't 
 support it explicitly.

 2. Use a library solution using string mixins (quite cumbersome 
 as a user, and probably also inefficient).

 3. Introduce high level dependencies in the language itself, at 
 least to do the formatting.

 So I was just trying to brainstorm alternatives that would 
 allow a library solution.

 The biggest hurdle is accessing to the caller's scope, so far 
 only string mixins get that. There could be perhaps a different 
 feature that does it, i.e. a way to define a (compile time) 
 function that get access to the caller's scope, but I'm not 
 sure we would actually want that.


Leave these library solutions aside and turn them into a language 
conduciveness integrated into the compiler.  Do you remember 
there was an x ​​in D1 time?

```d
// D1:
   writeln(x!"e697a5 e69cac e8aa9e"); // ζ—₯本θͺž
// D2:
   auto data = hexString!"e697a5 e69cac e8aa9e";
```

SDB 79
Oct 25 2023
prev sibling parent reply duckchess <duckchess chess.com> writes:
On Wednesday, 25 October 2023 at 15:05:52 UTC, Arafel wrote:

 On 25/10/23 13:29, Jonathan M Davis wrote:

 IMHO, mixins should be explicit, obvious, and greppable, and 
 adding a separate syntax for them which tries to hide them is 
 going to make the language worse. However a string is 
 generated, if the programmer wants to turn it into code, they 
 should just use mixin, and if it's ugly, it's ugly, but at 
 least it's clear what's going on.


 I agree, however the current options regarding string 
 interpolation seem to be suboptimal:

 1. Get a string interpolation that doesn't get you strings, and 
 that needs support from the called function (or only work in 
 specific cases, not for `foo(string bar);`. You also can't 
 assign to string, nor use it in most libraries that don't 
 support it explicitly.

 2. Use a library solution using string mixins (quite cumbersome 
 as a user, and probably also inefficient).

 3. Introduce high level dependencies in the language itself, at 
 least to do the formatting.

 So I was just trying to brainstorm alternatives that would 
 allow a library solution.

 The biggest hurdle is accessing to the caller's scope, so far 
 only string mixins get that. There could be perhaps a different 
 feature that does it, i.e. a way to define a (compile time) 
 function that get access to the caller's scope, but I'm not 
 sure we would actually want that.


from the discussion in the chat: the things that is bad about 
mixins is that they allow mutations, so implicitly mixin 
something in can cause unexpected things to happen. i suggested 
const_mixin() instead that captures the scope, but only readonly.

so

```d
template i(string s) { mixin = s; }
float foo = 42;
writeln(i!"${foo}"); //ok
writeln(i!"${foo++}"); // error, cant mutate foo. need to use 
explicit mixin(i!"${foo++}")

```

it would be a more hygienic version of the idea, but no idea if 
walter would accept this.
Oct 25 2023
parent reply bachmeier <no spam.net> writes:
On Wednesday, 25 October 2023 at 19:15:42 UTC, duckchess wrote:


 ```d
 writeln(i!"${foo++}"); // error, cant mutate foo. need to use 
 explicit mixin(i!"${foo++}")
 ```


If someone wants to do this, they clearly don't understand the 
purpose of string interpolation. Code like that should be 
reserved for the C preprocessor.
Oct 25 2023
next sibling parent matheus <matheus gmail.com> writes:
On Wednesday, 25 October 2023 at 20:07:32 UTC, bachmeier wrote:

 On Wednesday, 25 October 2023 at 19:15:42 UTC, duckchess wrote:


 ```d
 writeln(i!"${foo++}"); // error, cant mutate foo. need to use 
 explicit mixin(i!"${foo++}")
 ```


 If someone wants to do this, they clearly don't understand the 
 purpose of string interpolation. Code like that should be 
 reserved for the C preprocessor.


This is what I'd call a "job retaining" code! =]

Matheus.

PS: Remembering WB presentation this year at DConf, I'd like to 
know if this is case do go to his office or not.
Oct 25 2023
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 25 October 2023 at 20:07:32 UTC, bachmeier wrote:

 On Wednesday, 25 October 2023 at 19:15:42 UTC, duckchess wrote:


 ```d
 writeln(i!"${foo++}"); // error, cant mutate foo. need to use 
 explicit mixin(i!"${foo++}")
 ```


 If someone wants to do this, they clearly don't understand the 
 purpose of string interpolation. Code like that should be 
 reserved for the C preprocessor.




string s = $"Something {++foo}" or whatever since it's just 
normal code inside the {}
Oct 25 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/25/2023 4:29 AM, Jonathan M Davis wrote:

 IMHO, mixins should be explicit, obvious, and greppable, and adding a
 separate syntax for them which tries to hide them is going to make the
 language worse. However a string is generated, if the programmer wants to
 turn it into code, they should just use mixin, and if it's ugly, it's ugly,
 but at least it's clear what's going on.


Yes, that was and remains the rationale for mixin. We have plenty of experience 
with it now, and it's been good.

Trying to hide this stuff away is also what macros do, and every language that 
supports macros winds up with hellish incomprehensible code (that the authors
of 
such insist is beautiful!).

And lastly, the discomfort with this seems to be related to discomfort with 
tuples. D doesn't support tuples as well as it should, which results in people 
not using tuples where tuples are appropriate, and hence unfamiliarity with
them.

D is going to get better tuple support (like having functions able to return 
tuples), and when we do, I expect using tuples will become natural for D 
programming.
Oct 25 2023
prev sibling next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot wrote:

 can we please just have ```i"whatever ${var}"``` to return a 
 fully interpolated string, not a tuple, not a template or 
 anything.
 because the common use case is ```auto s = i"whatever 
 ${var}";```,
 so maybe just lower it into ```format("whatever %s", var)```.

 Then also introduce ```t"whatever ${var}"``` for a 
 tuple/template returned object as a completely seperate 
 proposal and you discuss whatever proposal is better for it 
 YADIP or 1037 or whatever.

 this way it's also a lot simpler to understand what is 
 happening for the users.


Interpolated strings, even if they look like it, are NOT strings. 
They are a obfuscated or better said, conveniently laid out 
source code.

They contain inside of them, between the {} program code even if 
it is just a variable name. Strings are strictly just data. 
Interpolated string is a mix of CODE and data.

By the very nature of what interpolated strings are it is not 
possible to treat them as strings.
Oct 21 2023
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 21 October 2023 at 18:14:55 UTC, Patrick Schluter 
wrote:

 On Saturday, 21 October 2023 at 12:38:52 UTC, Commander Zot 
 wrote:

 [...]


 Interpolated strings, even if they look like it, are NOT 
 strings. They are a obfuscated or better said, conveniently 
 laid out source code.

 They contain inside of them, between the {} program code even 
 if it is just a variable name. Strings are strictly just data. 
 Interpolated string is a mix of CODE and data.

 By the very nature of what interpolated strings are it is not 
 possible to treat them as strings.
Oct 21 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn wrote:




This isn't true. It is an object that can convert to string 
(similar to D's `alias toString this;`)
Oct 21 2023
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 21 October 2023 at 18:59:13 UTC, Adam D Ruppe wrote:

 On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn wrote:




 This isn't true. It is an object that can convert to string 
 (similar to D's `alias toString this;`)


Yes, but it's implied is what I meant
Oct 21 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 21 October 2023 at 19:07:07 UTC, Imperatorn wrote:

 On Saturday, 21 October 2023 at 18:59:13 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn wrote:




 This isn't true. It is an object that can convert to string 
 (similar to D's `alias toString this;`)


 Yes, but it's implied is what I meant


ie

```cs
		string name = "Johan";
		int age = 37;
		string s = $"Hello {name}, you are {age} years old";
		
		Console.WriteLine(s);
```

Would output Hello Johan, you are 37 years old.
Oct 21 2023
prev sibling parent reply Rumbu <rumbu rumbu.ro> writes:
On Saturday, 21 October 2023 at 18:59:13 UTC, Adam D Ruppe wrote:

 On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn wrote:




 This isn't true. It is an object that can convert to string 
 (similar to D's `alias toString this;`)


In fact neither, it's syntactic sugar.

```csharp
int count = 10;
string s = $"I drink {count} beers";
```

is syntactic sugar for:

```csharp
int count = 10;
DefaultInterpolationHandler dh = new 
DefaultInterpolationHandler();
dh.AppendLiteral("I drink ");
dh.AppendFormatted(count);
dh.AppendLiteral(" beers");
string s = dh.ToStringAndClear();
```

 From compiler point of view, Roslyn stores in AST a interpolated 
string as an array of expressions which get converted before IL 
compilation to the code above.
Oct 23 2023
next sibling parent reply matheus <matheus gmail.com> writes:
On Monday, 23 October 2023 at 14:12:25 UTC, Rumbu wrote:

 On Saturday, 21 October 2023 at 18:59:13 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn wrote:




 This isn't true. It is an object that can convert to string 
 (similar to D's `alias toString this;`)


 In fact neither, it's syntactic sugar.

 ```csharp
 int count = 10;
 string s = $"I drink {count} beers";
 ```

 is syntactic sugar for:
 ...


Maybe we're talking about the same thing or it changed, but I 
thought it was a syntactic sugar for string.format():

https://web.archive.org/web/20160304034509/https://roslyn.codeplex.com/discussions/570614

Matheus.
Oct 23 2023
parent Adam Wilson <flyboynw gmail.com> writes:
On Monday, 23 October 2023 at 14:44:49 UTC, matheus wrote:

 On Monday, 23 October 2023 at 14:12:25 UTC, Rumbu wrote:

 On Saturday, 21 October 2023 at 18:59:13 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn 
 wrote:




 This isn't true. It is an object that can convert to string 
 (similar to D's `alias toString this;`)


 In fact neither, it's syntactic sugar.

 ```csharp
 int count = 10;
 string s = $"I drink {count} beers";
 ```

 is syntactic sugar for:
 ...


 Maybe we're talking about the same thing or it changed, but I 
 thought it was a syntactic sugar for string.format():

 https://web.archive.org/web/20160304034509/https://roslyn.codeplex.com/discussions/570614

 Matheus.


The above is correct for what Roslyn does. The String.Format 
stuff comes in when you are trying to format the incoming 
variable, like so:
```csharp
string s = $"I drink {count:0000} beers";
```
Which will produce: "I drink 0010 beers"
Oct 24 2023
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 23 October 2023 at 14:12:25 UTC, Rumbu wrote:

 On Saturday, 21 October 2023 at 18:59:13 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn wrote:









Correct. But what I was trying to communicate it that it gives 
you a string by default.
Oct 23 2023
prev sibling parent reply Andrea Fontana <nospam example.org> writes:
On Monday, 23 October 2023 at 14:12:25 UTC, Rumbu wrote:

 On Saturday, 21 October 2023 at 18:59:13 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn wrote:




 This isn't true. It is an object that can convert to string 
 (similar to D's `alias toString this;`)


 In fact neither, it's syntactic sugar.

 ```csharp
 int count = 10;
 string s = $"I drink {count} beers";
 ```

 is syntactic sugar for:

 ```csharp
 int count = 10;
 DefaultInterpolationHandler dh = new 
 DefaultInterpolationHandler();
 dh.AppendLiteral("I drink ");
 dh.AppendFormatted(count);
 dh.AppendLiteral(" beers");
 string s = dh.ToStringAndClear();
 ```

 From compiler point of view, Roslyn stores in AST a 
 interpolated string as an array of expressions which get 
 converted before IL compilation to the code above.


I wonder why we can't do this in D, using text() or format() or 
everything else instead of returning tuples.

Andrea
Oct 25 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 25 October 2023 at 15:55:07 UTC, Andrea Fontana 
wrote:

 On Monday, 23 October 2023 at 14:12:25 UTC, Rumbu wrote:

 On Saturday, 21 October 2023 at 18:59:13 UTC, Adam D Ruppe 
 wrote:

 On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn 
 wrote:








 I wonder why we can't do this in D, using text() or format() or 
 everything else instead of returning tuples.

 Andrea


I can answer you, because we love bikeshedding :D

Each page represents a century, and a glowing marker points to 
the 90th page with a note saying 'String Interpolation in D - 
Still in Progress'. A robot stands nearby looking puzzled.
![Wait 1](https://i.ibb.co/b3mMnJM/wait1.webp)

Depiction of a sage on a mountaintop in a post-apocalyptic world. 
He holds a scroll that reads 'Prophecy: String Interpolation in D 
will take over 9000 years'. In the background, remnants of a lost 
civilization are visible.

![Wait 2](https://i.ibb.co/1Z07NQP/wait3.webp)
Oct 25 2023
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 October 2023 at 15:55:07 UTC, Andrea Fontana 
wrote:

 I wonder why we can't do this in D, using text() or format() or 
 everything else instead of returning tuples.


D *can* do this, but it has limitations that affect D uniquely.

D can manipulate types and aliases. Tuples are compatible with 
this.  Wrapper objects are not.

Besides, even if we gave up on type and alias support, implicit 
string interpolation is still problematic.

I've written about all this many, many times in previous dips and 
blog posts. That's why I wish this thread was closed. It has been 
done to death and you should read the old reports instead of 
running int he same circles over and over again.
Oct 25 2023
parent reply Andrea Fontana <nospam example.org> writes:
On Wednesday, 25 October 2023 at 18:22:50 UTC, Adam D Ruppe wrote:

 I've written about all this many, many times in previous dips 
 and blog posts. That's why I wish this thread was closed. It 
 has been done to death and you should read the old reports 
 instead of running int he same circles over and over again.


Send me a link about these things you wrote. I missed them. I 
would like to understand what's wrong with text() syntax sugar.

Andrea
Oct 25 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 October 2023 at 18:54:21 UTC, Andrea Fontana 
wrote:

 Send me a link about these things you wrote. I missed them. I 
 would like to understand what's wrong with text() syntax sugar.


http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html#my-string-interpolation-proposal

(in this one, i came out in favor of an object, but on the fence 
for implicit conversion to string, my position is now that the 
implicit conversion to string is undesirable, and this weakens 
the case of the object over the other alternatives)

https://github.com/dlang/DIPs/blob/344e00ee2d6683d61ee019d5ef6c1a0646570093/DIPs/DIP1036.md

(see also the linked review threads from that)

This isn't D specific, even Wikipedia has a page on it:

https://en.wikipedia.org/wiki/String_interpolation#Security_issues

And newer additions to languages try to do it right:

https://openjdk.org/jeps/430

Note:


 String interpolation is dangerous
 
 Unfortunately, the convenience of interpolation has a downside: 
 It is easy to construct strings that will be interpreted by 
 other systems but which are dangerously incorrect in those 
 systems.

 [snip ]
 
 Can we do better?
 
 For Java, we would like to have a string composition feature 
 that achieves the clarity of interpolation but achieves a safer 
 result out-of-the-box, perhaps trading off a small amount of 
 convenience to gain a large amount of safety.
Oct 25 2023
next sibling parent Meta <jared771 gmail.com> writes:
On Wednesday, 25 October 2023 at 19:09:30 UTC, Adam D Ruppe wrote:

 And newer additions to languages try to do it right:

 https://openjdk.org/jeps/430


That's cool, although in typical Java style, the feature's power 
is hamstrung:

```
Template processors execute at run time, not at compile time, so 
they cannot perform compile-time processing on templates. Neither 
can they obtain the exact characters which appear in a template 
in source code; only the values of the embedded expressions are 
available, not the embedded expressions themselves.

```

D has the opportunity to be on the very cutting edge here.
Oct 25 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/25/2023 12:09 PM, Adam D Ruppe wrote:

 And newer additions to languages try to do it right:
 
 https://openjdk.org/jeps/430


The money shot:

"The design of template expressions deliberately makes it impossible to go 
directly from a string literal or text block with embedded expressions to a 
String with the expressions' values interpolated. This prevents dangerously 
incorrect strings from spreading through a program."
Oct 25 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 26 October 2023 at 00:24:33 UTC, Walter Bright wrote:

 The money shot:

 "The design of template expressions deliberately makes it 
 impossible to go directly from a string literal or text block 
 with embedded expressions to a String with the expressions' 
 values interpolated. This prevents dangerously incorrect 
 strings from spreading through a program."


Yup. Even if we went with an object in D instead of a tuple, I'd 
be against the `alias toString this;` part. Just too much history 
saying that's a bad idea for D to embrace it at this point.
Oct 25 2023
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, October 25, 2023 7:47:33 PM MDT Adam D Ruppe via Digitalmars-d 
wrote:

 On Thursday, 26 October 2023 at 00:24:33 UTC, Walter Bright wrote:

 The money shot:

 "The design of template expressions deliberately makes it
 impossible to go directly from a string literal or text block
 with embedded expressions to a String with the expressions'
 values interpolated. This prevents dangerously incorrect
 strings from spreading through a program."


 Yup. Even if we went with an object in D instead of a tuple, I'd
 be against the `alias toString this;` part. Just too much history
 saying that's a bad idea for D to embrace it at this point.


Implicit conversions are fraught with dangers in general. Sometimes, they're
really useful to have, but they're often problematic, and they're even more
problematic in generic code. So, they should be used with care, and IMHO, we
should default to avoiding them rather than adding them.

- Jonathan M Davis
Oct 25 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 26 October 2023 at 02:02:49 UTC, Jonathan M Davis 
wrote:

 On Wednesday, October 25, 2023 7:47:33 PM MDT Adam D Ruppe via 
 Digitalmars-d wrote:

 On Thursday, 26 October 2023 at 00:24:33 UTC, Walter Bright 
 wrote:

 The money shot:

 "The design of template expressions deliberately makes it 
 impossible to go directly from a string literal or text 
 block with embedded expressions to a String with the 
 expressions' values interpolated. This prevents dangerously 
 incorrect strings from spreading through a program."


 Yup. Even if we went with an object in D instead of a tuple, 
 I'd be against the `alias toString this;` part. Just too much 
 history saying that's a bad idea for D to embrace it at this 
 point.


 Implicit conversions are fraught with dangers in general. 
 Sometimes, they're really useful to have, but they're often 
 problematic, and they're even more problematic in generic code. 
 So, they should be used with care, and IMHO, we should default 
 to avoiding them rather than adding them.

 - Jonathan M Davis


I'm just putting it here as an observation.

If D does not provide a way to implicitly get a string, it would 
be the *only* language that would do so.

All other languages with more than 10 users has a way to do that.

I even asked GPT-4 etc and it could not provide any examples of a 
language where you can't easily get a string from the expression 
or where it's the default.

As more or less the collective knowledge of humanity, maybe we 
should listen to it.

If we don't, it's more likely that we are wrong, not everyone 
else.
Oct 26 2023
prev sibling parent reply Arafel <er.krali gmail.com> writes:
On 26/10/23 3:47, Adam D Ruppe wrote:

 On Thursday, 26 October 2023 at 00:24:33 UTC, Walter Bright wrote:

 The money shot:

 "The design of template expressions deliberately makes it impossible 
 to go directly from a string literal or text block with embedded 
 expressions to a String with the expressions' values interpolated. 
 This prevents dangerously incorrect strings from spreading through a 
 program."


 
 Yup. Even if we went with an object in D instead of a tuple, I'd be 
 against the `alias toString this;` part. Just too much history saying 
 that's a bad idea for D to embrace it at this point.


You are not mentioning this part:


 The template expression STR."..." is a shortcut for invoking the process
method of the STR template processor. That is, the now-familiar example:
 
 String name = "Joan";
 String info = STR."My name is \{name}";
 
 is equivalent to:
 
 String name = "Joan";
 StringTemplate st = RAW."My name is \{name}";
 String info = STR.process(st);
 
 where RAW is a standard template processor that produces an unprocessed
StringTemplate object.


I would find it perfect if there were an option to define arbitrary 
prefixes to strings (other than the ones already used by the language), 
like `i"Hello, ${name}` or `sql"SELECT * FROM ${table};"`. Notice how 
the string itself doesn't need any marker in Java:


 String name = "Joan";
 String info = "My name is \{name}";
 | error: processor missing from template expression


It's needing both what I don't like and find confusing: `string s = 
i"Hello, ${world}".format` (or `.text`).

We can do like Java, and assume that as soon as a template expression is 
found, it will be automatically considered an interpolated string, so 
actually strings literals will be interpolated by default, and only if 
there are no expressions the result would be a `string`.
Oct 26 2023
next sibling parent duckchess <duckchess chess.com> writes:
On Thursday, 26 October 2023 at 09:42:27 UTC, Arafel wrote:

 On 26/10/23 3:47, Adam D Ruppe wrote:

 [...]


 You are not mentioning this part:


 [...]


 I would find it perfect if there were an option to define 
 arbitrary prefixes to strings (other than the ones already used 
 by the language), like `i"Hello, ${name}` or `sql"SELECT * FROM 
 ${table};"`. Notice how the string itself doesn't need any 
 marker in Java:


 [...]


 It's needing both what I don't like and find confusing: `string 
 s = i"Hello, ${world}".format` (or `.text`).

 We can do like Java, and assume that as soon as a template 
 expression is found, it will be automatically considered an 
 interpolated string, so actually strings literals will be 
 interpolated by default, and only if there are no expressions 
 the result would be a `string`.


with adams proposal you could do
```d
sql!i"SELECT * FROM > ${table};"
```

which is good enough. as walter will never agree to macros, adams 
proposal is the most simple and flexible design, so we should go 
for that.
Oct 26 2023
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 26 October 2023 at 09:42:27 UTC, Arafel wrote:

 On 26/10/23 3:47, Adam D Ruppe wrote:

 [...]


 You are not mentioning this part:


 [...]


 I would find it perfect if there were an option to define 
 arbitrary prefixes to strings (other than the ones already used 
 by the language), like `i"Hello, ${name}` or `sql"SELECT * FROM 
 ${table};"`. Notice how the string itself doesn't need any 
 marker in Java:


 [...]


 It's needing both what I don't like and find confusing: `string 
 s = i"Hello, ${world}".format` (or `.text`).

 We can do like Java, and assume that as soon as a template 
 expression is found, it will be automatically considered an 
 interpolated string, so actually strings literals will be 
 interpolated by default, and only if there are no expressions 
 the result would be a `string`.


Yes, if D doesn't provide that. It would be the only language 
(created by man at least) that does not give the user a string if 
desired.
Oct 26 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 26 October 2023 at 10:12:49 UTC, Imperatorn wrote:

 On Thursday, 26 October 2023 at 09:42:27 UTC, Arafel wrote:

 On 26/10/23 3:47, Adam D Ruppe wrote:

 [...]


 You are not mentioning this part:


 [...]


 I would find it perfect if there were an option to define 
 arbitrary prefixes to strings (other than the ones already 
 used by the language), like `i"Hello, ${name}` or `sql"SELECT 
 * FROM ${table};"`. Notice how the string itself doesn't need 
 any marker in Java:


 [...]


 It's needing both what I don't like and find confusing: 
 `string s = i"Hello, ${world}".format` (or `.text`).

 We can do like Java, and assume that as soon as a template 
 expression is found, it will be automatically considered an 
 interpolated string, so actually strings literals will be 
 interpolated by default, and only if there are no expressions 
 the result would be a `string`.


 Yes, if D doesn't provide that. It would be the only language 
 (created by man at least) that does not give the user a string 
 if desired.


Any DIP that doesn't provide a way to get a string from an 
interpolated string is almost useless to the users. And the 
language exists for the users. It doesn't exists for library 
writers.

At some point in life you would want at least 1 user to actually 
use some of the language or libraries. Otherwise it's just a 
hobby project, nothing wrong with that, but it's not professional.

I don't see how there would be even more than 0 users that would 
find not being able to get a string useful. And if they do, it's 
very likely they just don't care at all or simple don't use 
strings, which would make them very poor judges of the 
consequences.

In various branches or psychology there are terms for this. Where 
you agrue for something just because you don't want to face the 
consequences of the alternative.

This is where we are right now. Since it takes energy to provide 
the user (who in the end is who matters) a clean interface, you 
instead begin to argue that the user never needs it, not because 
it is true, but because you don't want to face the consequences 
of implementing it for the user, because it is a big task.

That is not good design, and has been proven over the centuries, 
that if you do something the main users don't find reasonable, it 
doesn't matter what you think of the design, the users will make 
it change.

Just because you are creating something, doesn't automatically 
imply that it's good, ergonomic, logical or useful.

In the end, something is only useful if it's used. And a solution 
pushing all the work to the user is not only unintuitive and 
unergonomic, it also barely passes the laugh test.

It's like arguing that it would be totally acceptable that from 
now on, if uses want an int, they can't just do "int x", they 
must now write "int.asint x".

You could of course argue for that it would be good. It's easy:

If you write int.asint you can more clearly see that's in an int 
than before, it's 100% more visible = great for the user. int 
should not implicitly give you an int, who would want that 
anyway, to miss the advantages of int.asint readability and 
clarity of mind.

Also, why would you want an int by default? Just because it's 
intuitive doesn't mean the language should provide it.

It's just a few more keystrokes, no big deal, the users can 
handle it.

And it would be great for library writers because now they can 
work with int and make the decision to get an int a user 
decision, it's great.

etc

Now go watch your language fade into oblivion like Malbolge, 
INTERCAL or <insert your favorite language here>.


There's a clear difference between languages that exist for the 
users and languages that just exist for the language creators and 
library writers. The latter category fades into oblivion very 
quickly.
Oct 26 2023
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 26 October 2023 at 10:40:34 UTC, Imperatorn wrote:

 On Thursday, 26 October 2023 at 10:12:49 UTC, Imperatorn wrote:

 On Thursday, 26 October 2023 at 09:42:27 UTC, Arafel wrote:

 On 26/10/23 3:47, Adam D Ruppe wrote:

 [...]


 You are not mentioning this part:


 [...]


 I would find it perfect if there were an option to define 
 arbitrary prefixes to strings (other than the ones already 
 used by the language), like `i"Hello, ${name}` or `sql"SELECT 
 * FROM ${table};"`. Notice how the string itself doesn't need 
 any marker in Java:


 [...]


 It's needing both what I don't like and find confusing: 
 `string s = i"Hello, ${world}".format` (or `.text`).

 We can do like Java, and assume that as soon as a template 
 expression is found, it will be automatically considered an 
 interpolated string, so actually strings literals will be 
 interpolated by default, and only if there are no expressions 
 the result would be a `string`.


 Yes, if D doesn't provide that. It would be the only language 
 (created by man at least) that does not give the user a string 
 if desired.


 Any DIP that doesn't provide a way to get a string from an 
 interpolated string is almost useless to the users. And the 
 language exists for the users. It doesn't exists for library 
 writers.


For reference, both Adam and Walter's versions show how it is 
possible with `.text` or `.format`.

https://github.com/dlang/dmd/pull/15722#issuecomment-1774153328
https://github.com/adamdruppe/interpolation-examples/blob/e275f110898758dbbbfaa5427a72c9a18387d065/01-basics.d#L13C25-L13C78

I'm sympathetic to not putting that functionality in the compiler.
Oct 26 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 26 October 2023 at 15:45:48 UTC, jmh530 wrote:


 For reference, both Adam and Walter's versions show how it is 
 possible with `.text` or `.format`.

 https://github.com/dlang/dmd/pull/15722#issuecomment-1774153328
 https://github.com/adamdruppe/interpolation-examples/blob/e275f110898758dbbbfaa5427a72c9a18387d065/01-basics.d#L13C25-L13C78

 I'm sympathetic to not putting that functionality in the 
 compiler.


I'd agree if the only thing I cared about is good language design 
and didn't care at all about usability. Why not this?

```
import std.format;
string s = $"Hello, ${world}";
```

Anyone that wants what's currently on offer could still do this 
if they want:

```
string s = i"Hello, ${world}".format;
```
Oct 26 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 26 October 2023 at 16:14:08 UTC, bachmeier wrote:

 Why not this?


https://en.wikipedia.org/wiki/String_interpolation#Security_issues
Oct 26 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 26 October 2023 at 16:25:26 UTC, Adam D Ruppe wrote:

 On Thursday, 26 October 2023 at 16:14:08 UTC, bachmeier wrote:

 Why not this?


 https://en.wikipedia.org/wiki/String_interpolation#Security_issues


I'm not going to be doing SQL injections against myself. I'd 
agree that this is an argument against having support for only 
one approach. Forbidding the convenient approach in the name of 
security should wait until pointers have been removed.
Oct 26 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 26 October 2023 at 17:09:31 UTC, bachmeier wrote:

 Forbidding the convenient approach in the name of security 
 should wait until pointers have been removed.


OK, that was done back in... i think 2011 when  safe came out.

So I guess we're due for something else!
Oct 26 2023
prev sibling next sibling parent reply Arafel <er.krali gmail.com> writes:
On 26/10/23 18:25, Adam D Ruppe wrote:

 On Thursday, 26 October 2023 at 16:14:08 UTC, bachmeier wrote:

 Why not this?


 
 https://en.wikipedia.org/wiki/String_interpolation#Security_issues
 


That's a weak argument. First, it's not specific to string interpolation:


 String interpolation, like string concatenation, may lead to security
problems. If user input data is improperly escaped or filtered


Should we also restrict string concatenation? Of course you'll get SQL 
injection if you don't sanitize strings!

What a security-conscious SQL function could do is not to accept normal 
strings, only the raw tuples returned by the lowering.

But this doesn't mean you need to restrict other valid usages where 
that's not a concern.
Oct 26 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 26 October 2023 at 17:29:16 UTC, Arafel wrote:

 Should we also restrict string concatenation?


String concatenation is inconvenient, so it is less appealing for 
casual use, but, yes, it is also generally problematic.

One of interpolation's benefits is to make concatenation less 
common. It would be nice to transition people to something that 
is both easier AND more correct.

I'm through with this thread btw.
Oct 26 2023
prev sibling next sibling parent Adam Wilson <flyboynw gmail.com> writes:
On Thursday, 26 October 2023 at 16:25:26 UTC, Adam D Ruppe wrote:

 On Thursday, 26 October 2023 at 16:14:08 UTC, bachmeier wrote:

 Why not this?


 https://en.wikipedia.org/wiki/String_interpolation#Security_issues


Unfortunately, this is about injection attacks, not 
auto-rendering, which are unrelated to whether or not the string 
is auto-rendered from it's tuples form. In both cases the 
formatter would have to take care of the escaping and filtering 
before it is rendered into a string.

Consider that the DIP currently allows auto-decoding on a string 
parameter of a method. What is the functional difference?

Furthermore, consider the following example:

```d

class Test {
     public string a;
     public  property string b(string value) { return a = value; }
}

Test.a = $"...{x}..."; //Compiler error
Test.b = $"...{x}..."; //No compiler error
```

This is one of those vexatious compiler errors that make no sense 
when you read the code, but makes sense to the compiler. And it 
doesn't actually solve anything, because the problem is with 
what's passed into the string tuples, not the fact of rendering 
or not.

There is a debate to be had about the foot-gun nature of all 
forms of string interpolation/templating, but disabling rendering 
on assignment has nothing to do with it.
Oct 27 2023
prev sibling parent duckchess <duckchess chess.com> writes:
On Thursday, 26 October 2023 at 16:25:26 UTC, Adam D Ruppe wrote:

 On Thursday, 26 October 2023 at 16:14:08 UTC, bachmeier wrote:

 Why not this?


 https://en.wikipedia.org/wiki/String_interpolation#Security_issues


I'd argue that this is a problem of the sql library accepting a 
string in the first place, not a problem of string interpolation 
resulting in a string.
not having implicit to string conversion doesnt prevent someone 
from doing
```sql_exec(i"...".text);```


i would have prefered a way to write sql"" instead of sql!i"" but 
ultimately it doesn't matter that much.

the difference of your dip to macros is that we are stuck with 
whatever syntax we pick for the capture, so probably ${}, so not 
big of a deal.

and if we wanted we could still introduce a rewrite of sql"" into 
sql!i"" later.
Oct 27 2023
prev sibling parent reply Arafel <er.krali gmail.com> writes:
On 26/10/23 18:14, bachmeier wrote:

 I'd agree if the only thing I cared about is good language design and 
 didn't care at all about usability. Why not this?
 
 |import std.format; string s = $"Hello, ${world}"; |
 
 Anyone that wants what's currently on offer could still do this if they 
 want:
 
 |string s = i"Hello, ${world}".format; |


Also, not allowing this would result confusing to new users for no good 
reason: you'll have to explain to them why `write(i"....");` works, but 
`string s = i"....";` doesn't, and how `i"..." isn't like `r"..." or 
`q"[...]"`.

And then, if I have to do `i"Hello, ${world}".format`, I can already 
just as well do `mixin(i!"Hello, ${world}")`. This doesn't require any 
change to the language and has the advantage (as a user) that it's a 
library solution and I can pick the one that best suits my needs.

But back to usability: that is the basic objective of the feature. 
Usability for the end user, not for the library writer.

String interpolation is meant to be high level syntax sugar to make 
things easy and straightforward, not some advanced topic where you need 
to understand how internal compiler tuples work to be able to know when 
you can use it.

So what will 90% of the users want and expect?

Just something that can act as a drop-in replacement for strings for 
basic usage, nothing fancy, don't care about performance. I use this all 
the time for scripting (bash, perl) and it's really convenient.

In D I'd like to do:

```d
// Read config
string basePath = readConfig("basePath");
string inputFolder = readConfig("inputFolder");
string outputFoler = readConfig("outputFolder");
Item[] items = readConfig("itemList");

// Process items
foreach(item; items) {
	string inputFile = i"${basePath}/${inputFolder}/${item.name}.in";
	string outputFile = i"${basePath}/${outputFolder}/${item.name}.out";
	log(i"Going to process input file ${inputFile}. Output will be written 
to ${outputFile}").
	processItem(item, inputFile, outputFile);
}
```

I write this kind of code all the time... in languages that support it. 
I would in D as well, if I had the feature. And yes, adding `.text` or 
`.format` would kill it just as adding `mixin(...)` does already.

Before somebody says I should just adapt `processItem`: in most cases I 
don't have control over it, and the creator of that library isn't likely 
in the mood to deal with templates and tuples, especially with two 
arguments. Why should he? He just wants two file names... and it could 
even be a C library.
Oct 26 2023
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 26 October 2023 at 16:42:23 UTC, Arafel wrote:

 On 26/10/23 18:14, bachmeier wrote:

 I'd agree if the only thing I cared about is good language 
 design and didn't care at all about usability. Why not this?
 
 |import std.format; string s = $"Hello, ${world}"; |
 
 Anyone that wants what's currently on offer could still do 
 this if they want:
 
 |string s = i"Hello, ${world}".format; |


 Also, not allowing this would result confusing to new users for 
 no good reason: you'll have to explain to them why 
 `write(i"....");` works, but `string s = i"....";` doesn't, and 
 how `i"..." isn't like `r"..." or `q"[...]"`.

 And then, if I have to do `i"Hello, ${world}".format`, I can 
 already just as well do `mixin(i!"Hello, ${world}")`. This 
 doesn't require any change to the language and has the 
 advantage (as a user) that it's a library solution and I can 
 pick the one that best suits my needs.

 But back to usability: that is the basic objective of the 
 feature. Usability for the end user, not for the library writer.

 String interpolation is meant to be high level syntax sugar to 
 make things easy and straightforward, not some advanced topic 
 where you need to understand how internal compiler tuples work 
 to be able to know when you can use it.

 So what will 90% of the users want and expect?

 Just something that can act as a drop-in replacement for 
 strings for basic usage, nothing fancy, don't care about 
 performance. I use this all the time for scripting (bash, perl) 
 and it's really convenient.

 In D I'd like to do:

 ```d
 // Read config
 string basePath = readConfig("basePath");
 string inputFolder = readConfig("inputFolder");
 string outputFoler = readConfig("outputFolder");
 Item[] items = readConfig("itemList");

 // Process items
 foreach(item; items) {
 	string inputFile = 
 i"${basePath}/${inputFolder}/${item.name}.in";
 	string outputFile = 
 i"${basePath}/${outputFolder}/${item.name}.out";
 	log(i"Going to process input file ${inputFile}. Output will be 
 written to ${outputFile}").
 	processItem(item, inputFile, outputFile);
 }
 ```

 I write this kind of code all the time... in languages that 
 support it. I would in D as well, if I had the feature. And 
 yes, adding `.text` or `.format` would kill it just as adding 
 `mixin(...)` does already.

 Before somebody says I should just adapt `processItem`: in most 
 cases I don't have control over it, and the creator of that 
 library isn't likely in the mood to deal with templates and 
 tuples, especially with two arguments. Why should he? He just 
 wants two file names... and it could even be a C library.


I would guess that std.logger would get support for i-strings. In 
that case, you would only need to call .text if you don't want to 
re-write processItem.

```d
// Read config
string basePath = readConfig("basePath");
string inputFolder = readConfig("inputFolder");
string outputFoler = readConfig("outputFolder");
Item[] items = readConfig("itemList");

// Process items
foreach(item; items) {
     auto inputFile = i"$basePath/$inputFolder/$(item.name).in";
     auto outputFile = i"$basePath/$outputFolder/$(item.name).out";
     log(i"Going to process input file $inputFile. Output will be 
written to $outputFile").
     processItem(item, inputFile.text, outputFile.text);
}
```
Oct 26 2023
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 26 October 2023 at 16:42:23 UTC, Arafel wrote:

 On 26/10/23 18:14, bachmeier wrote:

 I'd agree if the only thing I cared about is good language 
 design and didn't care at all about usability. Why not this?
 
 |import std.format; string s = $"Hello, ${world}"; |
 
 Anyone that wants what's currently on offer could still do 
 this if they want:
 
 |string s = i"Hello, ${world}".format; |


 Also, not allowing this would result confusing to new users for 
 no good reason: you'll have to explain to them why 
 `write(i"....");` works, but `string s = i"....";` doesn't, and 
 how `i"..." isn't like `r"..." or `q"[...]"`.

 And then, if I have to do `i"Hello, ${world}".format`, I can 
 already just as well do `mixin(i!"Hello, ${world}")`. This 
 doesn't require any change to the language and has the 
 advantage (as a user) that it's a library solution and I can 
 pick the one that best suits my needs.


I'm replying to you here Arafel, but it's meant as a general 
comment.

As someone who has been developing for many years in both small 
companies and large, using everything from C, C++,(Visual) Basic, 

know what works and what doesn't.

It's quite simple.

Keep it simple for the user. Have ergonomic syntax. Show that you 
care about the users feedback. Be reasonably performance, stable 
and safe.

The language exists for the users.

Nothing will change that fact, no matter what sequence of letters 
you put together.

And the users are saying, that if we should implement SI, there 
should exist an ergonomic way to get a string from the expression.

The users are not saying that that must be the *only* way, just 
that a way should exist that does not break the common interface. 
Many users are not in the forums at all btw.

Now, you can choose to ignore this, but in the end the same thing 
always happens. The users choose another language that is closer 
to the familiar interface.

The users don't care at all about what's good or bad under the 
hood.

They just care about how they use something.

And having to do an extra step in one language but not all the 
other breaks the common interface.

It's nothing more than that. So simple.

It might turn out that string interpolation is not worth it in D. 
Ok, then that's a decision that could be made.

But that decision should be made after you understand the 
consequences.

Also saying that it's the users loss if they move to another 
language, I must ask, are you sure about that?
Oct 26 2023
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/26/23 20:10, Imperatorn wrote:

 
 The users don't care at all about what's good or bad under the hood.
 
 They just care about how they use something.
 
 And having to do an extra step in one language but not all the other 
 breaks the common interface.
 
 It's nothing more than that. So simple.
 
 It might turn out that string interpolation is not worth it in D. Ok, 
 then that's a decision that could be made.
 
 But that decision should be made after you understand the consequences.
 
 Also saying that it's the users loss if they move to another language, I 
 must ask, are you sure about that?


Pretty much. Personally, I care about technical superiority of D more 
than popularity of D. Why does D need users that push for features 
causing security vulnerabilities or badly handled file paths?
Oct 27 2023
prev sibling parent kdevel <kdevel vogtner.de> writes:
On Thursday, 26 October 2023 at 16:42:23 UTC, Arafel wrote:

 [...]
 In D I'd like to do:

 ```d
 // Read config
 string basePath = readConfig("basePath");
 string inputFolder = readConfig("inputFolder");
 string outputFoler = readConfig("outputFolder");
 Item[] items = readConfig("itemList");

 // Process items
 foreach(item; items) {
 	string inputFile = 
 i"${basePath}/${inputFolder}/${item.name}.in";
 [...]
 ```

 I write this kind of code all the time...


Why? D has `buildPath` and `setExtension` [1]

```d
    string inputFile = buildPath (basePath, inputFolder, item)
       .setExtension ("in");
```

Okay, when `item` or `inputFolder` have leading path separators 
the result might surprise...

[1] https://dlang.org/phobos/std_path.html
Oct 26 2023
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 26 October 2023 at 15:45:48 UTC, jmh530 wrote:

 On Thursday, 26 October 2023 at 10:40:34 UTC, Imperatorn wrote:

 On Thursday, 26 October 2023 at 10:12:49 UTC, Imperatorn wrote:

 [...]


 Any DIP that doesn't provide a way to get a string from an 
 interpolated string is almost useless to the users. And the 
 language exists for the users. It doesn't exists for library 
 writers.


 For reference, both Adam and Walter's versions show how it is 
 possible with `.text` or `.format`.


I know.

https://github.com/dlang/dmd/pull/15722#issuecomment-1774153328

 https://github.com/adamdruppe/interpolation-examples/blob/e275f110898758dbbbfaa5427a72c9a18387d065/01-basics.d#L13C25-L13C78

 I'm sympathetic to not putting that functionality in the 
 compiler.


And the users are not. That's all I'm saying.
Oct 26 2023
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/26/23 19:38, Imperatorn wrote:

 I'm sympathetic to not putting that functionality in the compiler.


 
 And the users are not. That's all I'm saying.


I think it's a bit offensive to say people who do not agree with you are 
not users of the language.
Oct 27 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 27 October 2023 at 13:00:37 UTC, Timon Gehr wrote:

 On 10/26/23 19:38, Imperatorn wrote:

 I'm sympathetic to not putting that functionality in the 
 compiler.


 
 And the users are not. That's all I'm saying.


 I think it's a bit offensive to say people who do not agree 
 with you are not users of the language.


What has agreeing to do with any of this? It's just facts. Usage 
= you use it. If you don't use it, then you won't have a problem 
with it.

You just want to use the breaks in your car, you don't want to be 
unable to break just because some engineer thought it would be a 
good idea to add a captcha or solve a little puzzle before you 
can break.

That basically what the current implementation does. It forces 
the user to do something they are not used to having to do in any 
of the other 25+ languages they used before.

As I wrote before, it breaks the interface that is already 
established. Of course you can break it, but then you can't also 
be surprised if users complain.
Oct 27 2023
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/27/23 16:35, Imperatorn wrote:

 On Friday, 27 October 2023 at 13:00:37 UTC, Timon Gehr wrote:

 On 10/26/23 19:38, Imperatorn wrote:

 I'm sympathetic to not putting that functionality in the compiler.


 And the users are not. That's all I'm saying.


 I think it's a bit offensive to say people who do not agree with you 
 are not users of the language.


 
 What has agreeing to do with any of this? It's just facts. Usage = you 
 use it. If you don't use it, then you won't have a problem with it.
 ...


You conduct yourself as if there was some group of powerful stakeholders 
called "users" with a uniform and informed opinion on this matter that 
elected you as a representative.

I am a user of D. You don't speak for me.


 You just want to use the breaks in your car, you don't want to be unable 
 to break just because some engineer thought it would be a good idea to 
 add a captcha or solve a little puzzle before you can break.
 
 That basically what the current implementation does.


No, that's not true.


 It forces the user to do something they are not used to having to do in any of
the other 
 25+ languages they used before.
 ...


Sometimes there is a better solution.


 As I wrote before, it breaks the interface that is already established. 
 Of course you can break it, but then you can't also be surprised if 
 users complain.


I am not surprised, just disappointed at the quality of discourse.
Oct 27 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 27 October 2023 at 15:01:07 UTC, Timon Gehr wrote:

 On 10/27/23 16:35, Imperatorn wrote:

 On Friday, 27 October 2023 at 13:00:37 UTC, Timon Gehr wrote:

 On 10/26/23 19:38, Imperatorn wrote:








 You conduct yourself as if there was some group of powerful 
 stakeholders called "users" with a uniform and informed opinion 
 on this matter that elected you as a representative.


Yes, because there, is? Everything except that I have been 
elected.

Have you even tried opening a browser and checking? And if you 
don't have access to the world wide web then go to a library, and 
if there is no library nearby, go outside and talk to someone, 
anyone. Any developer should do basically.

It's unsettling how little work anyone want to do, just search 
for yourself. It takes 30 minutes to get a complete picture of 
the current state in all major languages having string 
interpolation.

Do we have to start at the bottom of the entire logical chain for 
it to become obvious?

0. The world exists βœ“
1. There are users βœ“
2. Some of them write programs βœ“
3. Many of the programs written in the last decade have string 
interpolation βœ“
4. All of them can give you a string without the user having to 
do anything βœ“

Now the question becomes:
Do you care about those users or not?

If not, then ok, just say so? I would respect that. But don't be 
surprised when they think you're doing something that feels 
unnatural to them. Like using a door, flipping a switch or 
whatever you do every day. If suddenly someone thought it would 
be a splendid idea to make you scream for 30 seconds straight to 
make the light bulb turn on, great, do that. But don't try force 
convince the rest of the world that your borderline psychotic 
behavior would be "normal" and that it would be offensive to 
question the design.


 That basically what the current implementation does.


 No, that's not true.


You just say "no" without providing any evidence. Why? Is itsome 
kind of Halloween thing


 Sometimes there is a better solution.


Here you are actually correct and have a point. There might be 
better solutions. And D might be the first to show that.

But think of it in terms of probability.

Is it more probable that we, or the rest of the world, are wrong?


 I am not surprised, just disappointed at the quality of 
 discourse.


Your subjective view of the quality of discourse is of course 
important, but it does not change any of the facts provided.



 Oct 27 2023



 next sibling parent reply Mike Parker <aldacron gmail.com>  writes:


On Friday, 27 October 2023 at 15:59:57 UTC, Imperatorn wrote:


 Your subjective view of the quality of discourse is of course 
 important, but it does not change any of the facts provided.


So then, please, let's all try to keep the quality of discourse 
up a bit and stay focused on the pros and cons of the competing 
string interpolation implementations.

Thanks!



 Oct 27 2023



 next sibling parent  bachmeier <no spam.net>  writes:


On Friday, 27 October 2023 at 16:04:26 UTC, Mike Parker wrote:


 So then, please, let's all try to keep the quality of discourse 
 up a bit and stay focused on the pros and cons of the competing 
 string interpolation implementations.


Yeah, we might have strong views about what is the best way to 
proceed, but we should assume everyone else is also trying to do 
what's best for the language. Expressions of diverse viewpoints 
ensures everyone is heard and that all issues come out. It's okay 
if we have different objectives/priorities/use cases.



 Oct 27 2023



prev sibling  parent  Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Friday, 27 October 2023 at 16:04:26 UTC, Mike Parker wrote:

 On Friday, 27 October 2023 at 15:59:57 UTC, Imperatorn wrote:


 Your subjective view of the quality of discourse is of course 
 important, but it does not change any of the facts provided.


 So then, please, let's all try to keep the quality of discourse 
 up a bit and stay focused on the pros and cons of the competing 
 string interpolation implementations.

 Thanks!


πŸ‘



 Oct 27 2023



prev sibling  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 10/27/23 17:59, Imperatorn wrote:

 That basically what the current implementation does.


 No, that's not true.


 
 You just say "no" without providing any evidence. Why?


What can be stated without evidence can be dismissed without evidence.
You made a ridiculous analogy. You are acting like people simply have to 
be crazy for not seeing it your way. Like in fact, the devil is not in 
the details.

I think concerns like the interpolated string expanding into multiple 
local variables being surprising behavior are much more important than 
claims like "you have to be crazy for not doing it like those 5 other 
languages, psychologists say so!".


 

 Sometimes there is a better solution.


 
 Here you are actually correct and have a point. There might be better
solutions. And D might be the first to show that.
 ...


Interestingly, no. The Java proposal linked earlier is similar in this 
respect.


 But think of it in terms of probability.
 
 Is it more probable that we, or the rest of the world, are wrong?


It has _already been shown to be a source of issues_. It's simply the 
power of hindsight, afforded to D because Walter has been somewhat 
conservative in adding new shiny features. D often ends up doing things 
somewhat differently to avoid pitfalls into which other languages have 
fallen. This is a meaningfully different endeavor to stupid straw-man 
proposals like breaking language changes such as `int.asint`, 
accident-inducing captcha on car breaks, or having lightbulbs be 
activated by 30 seconds of screaming.

When you engage in such comparisons, you are essentially saying 
"different implies worse. I don't have to make the case. if you were a 
reasonable person, you would already agree with me". The implication 
actually goes the other way around. But this is not surprising. Better 
is also always different.


 

 I am not surprised, just disappointed at the quality of discourse.


 
 Your subjective view of the quality of discourse is of course important, ...


Nothing particularly subjective about it. E.g., from you last post:


 But don't be surprised when they think you're doing something that feels
unnatural to them. Like using a door, flipping a switch or whatever you do
every day. If suddenly someone thought it would be a splendid idea to make you
scream for 30 seconds straight to make the light bulb turn on, great, do that.
But don't try force convince the rest of the world that your borderline
psychotic behavior would be "normal" and that it would be offensive to question
the design. 


This insulting hyperbole adds nothing to the discussion. All it does is 
attempt to discourage people from engaging in a discussion with you, 
because you accuse them of being crazy for having a nuanced perspective. 
You are also rudely twisting my words here. Questioning the design is a 
priori not offensive. I would be glad if you were just questioning the 
design. But maybe try accepting or critiquing some of the answers on 
their own merit and toning down your GPT-fueled fallacious rhetoric and 
appeals to popularity.


 ... but it does not change any of the facts provided. 


Well, in a high quality discourse, facts would be provided instead of 
personal attacks that are then critiqued in a meta-discussion advocating 
for basic civility. So yes, it would change the facts provided.



 Oct 27 2023



  parent reply Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Friday, 27 October 2023 at 21:19:43 UTC, Timon Gehr wrote:

 On 10/27/23 17:59, Imperatorn wrote:






There are no personal attacks.

The Java proposal is just a proposal, I am talking about the 
existing solutions that people use already.

Accusing people of weird things does not gain you any points or 
sympathy, it just shows you are not honest enough to see the 
facts without layers of politics, strategy or personal motives.

It's called motivated reasoning.

I don't have a hidden motive other than caring about the vast 
majority of users and making the probability that D gets more 
users higher.

It's totally fine if you don't care about those things, but then 
don't pretend that you do. That's the issue. Not the facts.

There could very well be a good reason you don't care about those 
things, but then just state them clearly.

For example:
"We know the majority of users expect A, but we still think this 
solution B is better, so much so that we are fully aware of the 
consequences and that it might very well lead to those expecting 
A not using D"

Or something like that.

Totally fine, just be honest about it.



 Oct 28 2023



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 10/28/23 11:08, Imperatorn wrote:






 
 There are no personal attacks.
 
 ...
 
 Accusing people of weird things does not gain you any points or 
 sympathy, it just shows you are not honest enough to see the facts 
 without layers of politics, strategy or personal motives.
 ...


Can't make this up. Shameless juxtaposition. 🀣

Anyway, you have well earned a spot in my Thunderbird kill file. Enjoy.



 Oct 28 2023



  parent reply Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Saturday, 28 October 2023 at 11:10:34 UTC, Timon Gehr wrote:

 On 10/28/23 11:08, Imperatorn wrote:






 
 There are no personal attacks.
 
 ...
 
 Accusing people of weird things does not gain you any points 
 or sympathy, it just shows you are not honest enough to see 
 the facts without layers of politics, strategy or personal 
 motives.
 ...


 Can't make this up. Shameless juxtaposition. 🀣


Your lack of imagination does not change the facts.


 Anyway, you have well earned a spot in my Thunderbird kill 
 file. Enjoy.


I have no idea why sharing that would be interesting to anyone. 
But ok, now we know πŸ‘



 Oct 28 2023



  parent reply Hors <ho rs.com>  writes:


On Saturday, 28 October 2023 at 11:35:53 UTC, Imperatorn wrote:

 On Saturday, 28 October 2023 at 11:10:34 UTC, Timon Gehr wrote:

 On 10/28/23 11:08, Imperatorn wrote:






 
 There are no personal attacks.
 
 ...
 
 Accusing people of weird things does not gain you any points 
 or sympathy, it just shows you are not honest enough to see 
 the facts without layers of politics, strategy or personal 
 motives.
 ...


 Can't make this up. Shameless juxtaposition. 🀣


 Your lack of imagination does not change the facts.


 Anyway, you have well earned a spot in my Thunderbird kill 
 file. Enjoy.


 I have no idea why sharing that would be interesting to anyone. 
 But ok, now we know πŸ‘


when will you two stop filling this topic with trash messages



 Oct 28 2023



  parent  Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Saturday, 28 October 2023 at 12:41:42 UTC, Hors wrote:

 On Saturday, 28 October 2023 at 11:35:53 UTC, Imperatorn wrote:

 On Saturday, 28 October 2023 at 11:10:34 UTC, Timon Gehr wrote:

 On 10/28/23 11:08, Imperatorn wrote:

 [...]


 Can't make this up. Shameless juxtaposition. 🀣


 Your lack of imagination does not change the facts.


 Anyway, you have well earned a spot in my Thunderbird kill 
 file. Enjoy.


 I have no idea why sharing that would be interesting to 
 anyone. But ok, now we know πŸ‘


 when will you two stop filling this topic with trash messages


I hope soon :D



 Oct 28 2023



prev sibling  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 10/27/23 16:35, Imperatorn wrote:

 If you don't use it, then you won't have a problem with it.


You are changing the topic here, but if a feature is going to be added, 
I'd rather have it be one I'd use reasonably often.



 Oct 27 2023



prev sibling  parent reply IGotD- <nise nise.com>  writes:


On Thursday, 26 October 2023 at 10:40:34 UTC, Imperatorn wrote:

 Any DIP that doesn't provide a way to get a string from an 
 interpolated string is almost useless to the users. And the 
 language exists for the users. It doesn't exists for library 
 writers.


I've not been following the string interpolation debate because 
I'm not a big user of string interpolation but this made me wake 
up. Are you seriously proposing a design that cannot convert a 
string interpolated string into a regular string?


 There's a clear difference between languages that exist for the 
 users and languages that just exist for the language creators 
 and library writers. The latter category fades into oblivion 
 very quickly.


This is a trap that many compiler engineers fall into, not only D 
but I have also observed the same among other languages. These 
are usually "hobbyist" languages and not languages that big 
companies are involved with.

The compiler engineers at some point forget that computer 
languages are made to make it easier for humans and not to make 
it easier for the computer or the language developer. I've seen 
several motivations like "that will make things so difficult" or 
"it will mess up my beautiful compiler code".

Examples of this is, not supporting early returns because program 
flow analysis of early returns is "difficult".
Another example is D with not supporting this() constructor for 
structs. A workaround in order to add it into the syntax is 
obviously not allowed.

D started out really well by departing from the horrible C++ 
syntax in order to make more readable, these days D seem to have 
abandon this heritage.



 Oct 27 2023



 next sibling parent  Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Friday, 27 October 2023 at 09:30:46 UTC, IGotD- wrote:

 On Thursday, 26 October 2023 at 10:40:34 UTC, Imperatorn wrote:


 I've not been following the string interpolation debate because 
 I'm not a big user of string interpolation but this made me 
 wake up. Are you seriously proposing a design that cannot 
 convert a string interpolated string into a regular string?


Yes, neither proposal gives you a string by default. I am trying 
to argue that most users would find that unergonomic and 
unintuitive. Most languages I have checked give you a string by 
default since it follows the principle of least astonishment.



 Oct 27 2023



prev sibling  parent reply Arafel <er.krali gmail.com>  writes:


On 27/10/23 11:30, IGotD- wrote:

 I've not been following the string interpolation debate because I'm not 
 a big user of string interpolation but this made me wake up. Are you 
 seriously proposing a design that cannot convert a string interpolated 
 string into a regular string?


Yes, these are the current proposals.

Or at least not directly. You'll need to call a function for that.

So this will work:

```d
writeln(i"Hello, ${name}");
```

But this won't:

```d
string greeting = i"Hello, ${name}";
```

and you will need to do:

```d
string greeting = i"Hello, ${name}".text;
```

Walter's proposal is essentially the same in that regard, only using 
`writefln` and `format` instead of `write` and `text`.

Good luck explaining these subtleties to new / casual users.



 Oct 27 2023



 next sibling parent reply IGotD- <nise nise.com>  writes:


On Friday, 27 October 2023 at 09:47:15 UTC, Arafel wrote:

 Yes, these are the current proposals.

 Or at least not directly. You'll need to call a function for 
 that.

 So this will work:

 ```d
 writeln(i"Hello, ${name}");
 ```

 But this won't:

 ```d
 string greeting = i"Hello, ${name}";
 ```

 and you will need to do:

 ```d
 string greeting = i"Hello, ${name}".text;
 ```

 Walter's proposal is essentially the same in that regard, only 
 using `writefln` and `format` instead of `write` and `text`.

 Good luck explaining these subtleties to new / casual users.


Can't this be solved by adding a constructor in the string class 
that accepts whatever type the interpolated string is?



 Oct 27 2023



  parent reply Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Friday, 27 October 2023 at 11:53:24 UTC, IGotD- wrote:

 On Friday, 27 October 2023 at 09:47:15 UTC, Arafel wrote:

 Yes, these are the current proposals.

 Or at least not directly. You'll need to call a function for 
 that.

 So this will work:

 ```d
 writeln(i"Hello, ${name}");
 ```

 But this won't:

 ```d
 string greeting = i"Hello, ${name}";
 ```

 and you will need to do:

 ```d
 string greeting = i"Hello, ${name}".text;
 ```

 Walter's proposal is essentially the same in that regard, only 
 using `writefln` and `format` instead of `write` and `text`.

 Good luck explaining these subtleties to new / casual users.


 Can't this be solved by adding a constructor in the string 
 class that accepts whatever type the interpolated string is?


Would be nice yes



 Oct 27 2023



  parent reply Arafel <er.krali gmail.com>  writes:


On 27/10/23 13:59, Imperatorn wrote:

     Can't this be solved by adding a constructor in the string class
     that accepts whatever type the interpolated string is?
 
 Would be nice yes
 


Not possible. A string in D is just another name (literally, just an 
alias) for an array of immutable chars. So there is no string class, and 
no constructor to speak of, other than the generic array constructor.

Technically, the best solution would probably be to return a (templated) 
struct with an "alias this" to the already interpolated string, and all 
other interpolation information also included, so functions would be 
able to choose what to accept.

But "alias this" is just a way to have implicit casting, and that's 
something (probably rightly) opposed here on principle, so I don't think 
we'll be having it anytime soon.



 Oct 27 2023



 next sibling parent reply IGotD- <nise nise.com>  writes:


On Friday, 27 October 2023 at 12:55:35 UTC, Arafel wrote:

 Not possible. A string in D is just another name (literally, 
 just an alias) for an array of immutable chars. So there is no 
 string class, and no constructor to speak of, other than the 
 generic array constructor.

 Technically, the best solution would probably be to return a 
 (templated) struct with an "alias this" to the already 
 interpolated string, and all other interpolation information 
 also included, so functions would be able to choose what to 
 accept.

 But "alias this" is just a way to have implicit casting, and 
 that's something (probably rightly) opposed here on principle, 
 so I don't think we'll be having it anytime soon.


Why does this work?

void func(string a)
{
...
}

func("string literal");



 Oct 27 2023



  parent  Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Friday, October 27, 2023 7:20:33 AM MDT IGotD- via Digitalmars-d wrote:

 On Friday, 27 October 2023 at 12:55:35 UTC, Arafel wrote:

 Not possible. A string in D is just another name (literally,
 just an alias) for an array of immutable chars. So there is no
 string class, and no constructor to speak of, other than the
 generic array constructor.

 Technically, the best solution would probably be to return a
 (templated) struct with an "alias this" to the already
 interpolated string, and all other interpolation information
 also included, so functions would be able to choose what to
 accept.

 But "alias this" is just a way to have implicit casting, and
 that's something (probably rightly) opposed here on principle,
 so I don't think we'll be having it anytime soon.


 Why does this work?

 void func(string a)
 {
 ...
 }

 func("string literal");


Because the type of "string literal" is string  - which as Arafel correctly
points out is immutable(char)[]. No conversion is taking place here
whatsoever.

Now, the compiler does have some extra logic where it will potentially
treat a literal as other types for you. E.G. if func took wstring,
it would just treat the literal as a wstring instead of explicitly requiring
that you use "string literal"w. Similarly, you can do

ubyte i = 1; // 1 is an int
ushort[] arr = [1, 2, 42, 22]; // the array literal is int[]

Literals have a default type which you can see if you use typeof on them,
but they can be treated as a variety of types by the compiler (null and []
are really good examples of that). And that's different from implicit
conversions, because the kind of conversions that are allowed are sometimes
completly different from what you can do with actual variables (e.g. you
can't convert int[] to ubyte[] like the compiler will do with literals
without allocating an entirely different array).

Once a literal is assigned to a variable (or even simply cast to
a specific type), then you're converting a value with a fixed type, not a
literal, and the normal rules for conversion are followed.

And the compiler couldn't do the kind of stuff that it does with literals
with interpolated strings, because those aren't values that are known at
compile time. The compiler is then dealing with actual objects with a
specific type rather than a literal that can be interpreted as a variety of
types based on how it's used.

Of course, we could have implicit conversions to string from whatever the
string inteperolation generates (e.g. by having alias this on that type),
but then that opens up all of the doors that implicit conversions do, which
is particularly problematic with generic code. It also requires that the
type know how to convert itself to a string as opposed to providing a
building block for library code to generate a string from it, which would
mean putting the formatting logic in the compiler, which arguably isn't a
great idea.

- Jonathan M Davis



 Oct 27 2023



prev sibling  parent  Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Friday, 27 October 2023 at 12:55:35 UTC, Arafel wrote:

 On 27/10/23 13:59, Imperatorn wrote:

 [...]


 Not possible. A string in D is just another name (literally, 
 just an alias) for an array of immutable chars. So there is no 
 string class, and no constructor to speak of, other than the 
 generic array constructor.

 Technically, the best solution would probably be to return a 
 (templated) struct with an "alias this" to the already 
 interpolated string, and all other interpolation information 
 also included, so functions would be able to choose what to 
 accept.

 But "alias this" is just a way to have implicit casting, and 
 that's something (probably rightly) opposed here on principle, 
 so I don't think we'll be having it anytime soon.


I don't mean any of those solutions. I mean that it would do what 




 Oct 27 2023



prev sibling  parent reply jmh530 <john.michael.hall gmail.com>  writes:


On Friday, 27 October 2023 at 09:47:15 UTC, Arafel wrote:

 [snip]
 Good luck explaining these subtleties to new / casual users.


We can add an error message when assigning to a string that tells 
the user to call `.text` or whatever if they want the string.

I tried to think of when I just want a string after doing 
interpolation (as opposed to writing immediately somehow) and 
struggled a bit. I think it would be usually in a string 
concatenation situation. So I asked Adam on his PR whether this 
works

```d
auto x = 1;
auto y = 2;
auto s1 = i"The value of x is $x,";
auto s2 = i"and the value of y is $y.";
writeln(i"$s1 $s2");
```

and he says it does.

Something like `writeln(s1, " ", s2)` would also work.



 Oct 27 2023



 next sibling parent  matheus <matheus gmail.com>  writes:


On Friday, 27 October 2023 at 12:49:24 UTC, jmh530 wrote:

 On Friday, 27 October 2023 at 09:47:15 UTC, Arafel wrote:

 [snip]
 Good luck explaining these subtleties to new / casual users.


 We can add an error message when assigning to a string that 
 tells the user to call `.text` or whatever if they want the 
 string.


But imagine that instead of "string" was "auto":

auto greeting = i"Hello, ${name}";

Maybe the user (Newcomer!?) is expecting a string in this "auto" 
greeting. The error message will be showed late only when the 
string conversion is expected not where was defined.

Matheus.



 Oct 27 2023



prev sibling  parent reply Arafel <er.krali gmail.com>  writes:


On 27/10/23 14:49, jmh530 wrote:

 I tried to think of when I just want a string after doing interpolation 
 (as opposed to writing immediately somehow) and struggled a bit.


I, on the other hand, do it constantly, especially when dealing with 
external libraries / systems.

Here is the first short and almost self-contained real-world example 
that I found having a quick look at my code. Just see how I construct 
and use `mailOrder` and `input`:

```d

/* This is another function in my small utility library.
  * Spawns a process, eventually remotely, with the given command line 
and standard input, returning a tuple with the status code, the captured 
stdout and the captured stderr.
  */
auto pipeProcess(string command, string stdin, string host = null, 
string remoteLauncher = "ssh");

bool sendEmail(string toAddr, string fromAddr, string fromName, string 
subject, string body, bool dryRun = false) {
     string mailOrder = "sendmail -f" ~ fromAddr ~ " -F\"" ~ fromName ~ 
"\" " ~ toAddr;
     string input = "To: " ~ toAddr ~ "\nSubject: " ~ subject ~ "\n" ~ body;

     try {
         if (!dryRun) {
             auto mailExec = pipeProcess(mailOrder, input);
             if (mailExec.status != 0) {
                 error("Error sending mail order: ", 
mailOrder,"\nstdin\n-----\n", input,
                         "stdout\n------\n", mailExec.output,
                         "\nstderr\n------\n", mailExec.error);
                 return false;
             }
         } else {
             warning("DRY RUN: not sending message:", mailOrder,"\n", 
input);
         }
     } catch (Exception e) {
         error(e);
         return false;
     }
     return true;
}
```

It would be fun, because `error` and `warning` would take interpolated 
strings directly, but I would need to add `.text` to construct 
`mailOrder` and `input`. Not confusing at all.

And please let's not start into why I call sendmail, why I don't use an 
existing mail library, or why I don't implement a SMTP client myself. 
Any of these solutions could probably be made to work, but would take 
longer and wouldn't be as simple, flexible, and adapted to **my** needs 
as this. Also, this already exists and works.

I also don't care about the glaring command injection possibility here, 
because this code has no user interaction whatsoever with all the inputs 
controlled by me. Also, how exactly would making me add `.text` prevent 
the injection?

Now you will tell me, I could rewrite pipeProcess to accept interpolated 
strings **as well**. But even if I only consider the first two 
parameters that I'm using in this example, I'd need four overloads: one 
taking both strings, one taking both interpolated strings, and one for 
each of the parameters as interpolated string. Less than optimal.

Well, or do some template parameter wizardry which I'm not exactly keen 
on. How would that work with default parameters, by the way?

Heck, anyway, what about the last two parameters? Who knows if I will 
ever want to do:

```d
remoteLauncher = "ssh -l " ~ userName ~ " -i " ~ identityFile;
```

Should my `pipeProcess` also accept interpolated strings there? How many 
overloads do I need now?



 Oct 27 2023



  parent  jmh530 <john.michael.hall gmail.com>  writes:


On Friday, 27 October 2023 at 14:16:01 UTC, Arafel wrote:

 On 27/10/23 14:49, jmh530 wrote:

 I tried to think of when I just want a string after doing 
 interpolation (as opposed to writing immediately somehow) and 
 struggled a bit.


 I, on the other hand, do it constantly, especially when dealing 
 with external libraries / systems.

 Here is the first short and almost self-contained real-world 
 example that I found having a quick look at my code. Just see 
 how I construct and use `mailOrder` and `input`:

 [snip]


Honestly, I don't see that much of an issue with `.text`, but I 
suppose I get that it would be an issue for new users. 
Personally, I would just do the template version of what you 
discussed and rejected, but if that's not for you, that's fine 
too.

One thing I considered was if you just are able to assign to a 
string if you don't use any formatting, but I think that leads to 
confusion as well. Either you go all the way or you don't.



 Oct 27 2023



prev sibling  parent reply kdevel <kdevel vogtner.de>  writes:


On Thursday, 26 October 2023 at 09:42:27 UTC, Arafel wrote:

 [...]
 I would find it perfect if there were an option to define 
 arbitrary prefixes to strings [...] like [...] `sql"SELECT * 
 FROM ${table};"`.


What should the type and the value of that expression be?



 Oct 26 2023



  parent  Arafel <er.krali gmail.com>  writes:


On 26/10/23 13:41, kdevel wrote:

 On Thursday, 26 October 2023 at 09:42:27 UTC, Arafel wrote:

 [...]
 I would find it perfect if there were an option to define arbitrary 
 prefixes to strings [...] like [...] `sql"SELECT * FROM ${table};"`.


 
 What should the type and the value of that expression be?


If this is to be a flexible solution to build libraries upon, I would 
say that whatever the writer of the interpolation "function" decides.

Now, a bit like Java, the **standard library** (not the language, or 
even druntime) should offer a "basic" intrerpolation function (or 
template, or mixin, or whatever is the underlying mechanism) where you 
get a string with some sane default formatting, something that people 
can use where a string would otherwise be expected.

Corner cases (like taking references, although the ref rvalue DIP might 
be useful here) might be acceptable, but it should Just Workβ„’ in most 
normal situations.



 Oct 26 2023



prev sibling  parent reply kdevel <kdevel vogtner.de>  writes:


On Saturday, 21 October 2023 at 18:14:55 UTC, Patrick Schluter 
wrote:

 [...]
 By the very nature of what interpolated strings are it is not 
 possible to treat them as strings.


True. BTW: How can interpolations be wrapped? Consider the 
follwing code fragment

```d
     auto query = i"select a from b where c = ${d}";
```

occurring in the same code unit as

```d
     auto path = i"${basepath}/${configdir1}/${filename}";
```

How can one selectively wrap only those interpolations which 
concatenate path components but leave the sql queries untouched? 
If one used buildPath [1] from the very start this would be a 
non-problem.


[1] 
https://forum.dlang.org/post/jctprfyaolylrxwoymjm forum.dlang.org



 Nov 01 2023



  parent  Adam D Ruppe <destructionator gmail.com>  writes:


On Wednesday, 1 November 2023 at 21:24:44 UTC, kdevel wrote:

 How can one selectively wrap only those interpolations which 
 concatenate path components but leave the sql queries untouched?


You buildPath(path) and db.query(query)...

the intermediate variables still contain the unprocessed sequence 
suitable for passing to a function that knows how to use it.

See: 
https://github.com/dlang/dmd/pull/15715#issuecomment-1781745762

for details (and as i say there, you can ask the compiler! I have 
a full implementation with many runnable examples all right there)



 Nov 01 2023



prev sibling  parent reply djent <djent example.com>  writes:


Much like the entrepreneur, the language designer is tasked with 
the difficult job of predicting what users would want in contrast 
with what they currently have and expect. This is how innovation 
materializes.

After giving Adam's implementation a spin, I'm convinced this is 
the proper way to move forward despite not having conceived it as 
a possibility beforehand. It's powerful, exploiting D's superior 
metaprogramming and DBI capabilities, but doesn't stray too far 
from the current situation found in many languages in that one 
can just use `text` or something similar if a plain string is 
required.

I anticipate the worst solution will win out given Walter's 
disposition, but I nonetheless hope for the best.



 Oct 27 2023



 next sibling parent  IGotD- <nise nise.com>  writes:


On Friday, 27 October 2023 at 19:18:08 UTC, djent wrote:

 After giving Adam's implementation a spin, I'm convinced this 
 is the proper way to move forward despite not having conceived 
 it as a possibility beforehand. It's powerful, exploiting D's 
 superior metaprogramming and DBI capabilities, but doesn't 
 stray too far from the current situation found in many 
 languages in that one can just use `text` or something similar 
 if a plain string is required.


Which makes me wonder is there a way to open up for implicit 
conversions? C++ has this which I kind of like.
Can we meet in the middle of road and allow implicit conversions 
in some cases?



 Oct 27 2023



prev sibling  parent  "H. S. Teoh" <hsteoh qfbox.info>  writes:


On Fri, Oct 27, 2023 at 07:18:08PM +0000, djent via Digitalmars-d wrote:

 Much like the entrepreneur, the language designer is tasked with the
 difficult job of predicting what users would want in contrast with
 what they currently have and expect. This is how innovation
 materializes.
 
 After giving Adam's implementation a spin, I'm convinced this is the
 proper way to move forward despite not having conceived it as a
 possibility beforehand. It's powerful, exploiting D's superior
 metaprogramming and DBI capabilities, but doesn't stray too far from
 the current situation found in many languages in that one can just use
 `text` or something similar if a plain string is required.
 
 I anticipate the worst solution will win out given Walter's
 disposition, but I nonetheless hope for the best.


I also hope that Adam's approach will win.  To me, it's the design that
best leverages the existing strengths of D: metaprogramming, DbI, and
strikes a pretty good balance between power and convenience.  This gives
it the potential address many of the issues that were brought up against
string interpolation -- having it integrate well into DbI means you
actually have a fighting chance of mitigating such issues without adding
yet another hack into the compiler/language.

Walter's solution in contrast seems rather lackluster, it solves only
one specific case but leaves other use cases out in the cold, and we
eventually end up with yet another half-baked feature that works well
enough on its own but doesn't really integrate deeply with the rest of
the language.


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose
Bierce



 Oct 27 2023