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);
}
```

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.

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.

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.

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.