String interpolation, after a healthy debate on discord

[bauss]

On Tuesday, 14 December 2021 at 09:35:27 UTC, WebFreak001 wrote:
> On Tuesday, 14 December 2021 at 09:10:07 UTC, Ogi wrote:
>> On Friday, 10 December 2021 at 18:39:32 UTC, WebFreak001 wrote:
>>> if that's your pain point, check out this proposal here: 
>>> https://forum.dlang.org/thread/kivjspiezjvqxjkhiugj@forum.dlang.org :)
>>
>> It’s not just my pain point though. We need to convert stuff 
>> to strings all the time. For example, every time we want a 
>> meaningful message in an assertion or an exception. Many 
>> Phobos modules have to import `std.format` or `std.conv` just 
>> for that.
>>
>> To my understanding, this proposal already requires moving 
>> `text` functionality into compiler (if it’s not there already, 
>> I don’t know). So why not just make one more step forward and 
>> allow converting istrings to strings? If implicit conversion 
>> is too much to ask for, it could be an explicit cast to 
>> string, or some property. Maybe `stringof` should do exactly 
>> that?
>
> no this proposal does not suggest moving any functionality into 
> the compiler. It suggests to add the istrings (tuples with 
> header) as described in the YAIDIP and have special function 
> calling syntax (`functionName"istring contents"`) that will 
> call any function, that accepts an istring as only argument. 
> The `text` function from `std.conv` would implement an overload 
> accepting an istring, which can then be called `text"istring 
> contents"` (same as `text(i"istring contents")`) and be the 
> idiomatic string building function using the GC.
>
> Then with the other linked proposal you could add `std.conv` 
> (or a custom wrapper that only imports `std.conv:text`, maybe 
> aliased) as default-import to all files in your project, so you 
> can just type `text"istring contents"` to make strings without 
> needing to import std.conv anywhere.

While I completely understand the proposal then I think it's the 
wrong approach as it adds an infinite amount of complexity for 
something that barely solves any issues that exist today.

Arguably while it solves some problems it's definitely going to 
introduce new issues with it.

Has D forgotten Scott's talk, along with the common saying that 
sometimes less is more?

D has so many concepts that it's almost impossible to wrap your 
head around D idioms and be an expert at D since there are so 
many edge-cases for each feature, so many issues that each 
feature tries to solve.

Every feature D gets added is always added in the most complex 
way possible to solve as many problems as possible, instead of 
just solving a handful of problems that are mostly relevant then 
D tries to solve ALL problems, relevant or not.

It's ultimately D's downfall that features are too complex.