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.

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.

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?

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.

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.