On Friday, 10 December 2021 at 13:51:16 UTC, Ogi wrote:

if that's your pain point, check out this proposal here: https://forum.dlang.org/thread/kivjspiezjvqxjkhiugj@forum.dlang.org :)

On Thursday, 9 December 2021 at 21:06:11 UTC, WebFreak001 wrote:

IMHO, this can be done through string mixins. But mixins have a large syntax (This is very strange for a language in which closures can be written as {code}.). If it was possible to write instead of mixin(i!"2 + 3 = ${2 + 3}") something like this #i!"2 + 3 = ${2 + 3}", then this DIP would not be needed. Then it would be possible not only to do string interpolation, for example:

JSON j = #jsonlit!q{
	"any" ~ "d_expr": 5 + 6,
	"key": data.map!(func).array,
};

On Friday, 10 December 2021 at 18:39:32 UTC, WebFreak001 wrote:

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?

On Tuesday, 14 December 2021 at 09:10:07 UTC, Ogi wrote:

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.

On Tuesday, 14 December 2021 at 09:35:27 UTC, WebFreak001 wrote:

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.

On Tuesday, 14 December 2021 at 09:35:27 UTC, WebFreak001 wrote:

I was referring to YAIDIP. According to it, istring should be allowed in mixin, pragma(msg) and assert (missed this one). This requires reimplementing text in the compiler.

On Tuesday, 14 December 2021 at 09:50:15 UTC, bauss wrote:

I think the complexity for the syntax and the language itself is quite little - and it's basically the same thing as JS template string literals too, but with the special ignore cases for letters i/r/q. It's not going to solve any issues if nobody implements it. It's completely just an extension to the language, but then is going to be a big help to making both more pretty code with text

The implementation of these functions is going to be a little complex.

I can see that the new istring calling syntax could introduce issues if we want to add more string types through prefixes in the future, but I think that would be worth it for a quite versatile feature. The feature in other languages (like JS) has shown great use-cases, an example: https://github.com/kay-is/awesome-tagged-templates

^ that link contains lots of cool examples we could have in D like that too. Some type-safe data structure creation helper, some string / template language processors with nicer syntax, some useful every-day utilities.

I think overall it will solve more issues than introducing new ones.

it's a complex feature. However you don't really care about its implementation or complexity unless you want to implement a function for it yourself. All the average user might even want to think about is text"...", which you could look at like it's special language syntax. It's something library authors can use and document to make more readable, better library functions.

Overall I think there is more benefit in adding this than not adding this.

On Tuesday, 14 December 2021 at 09:50:15 UTC, bauss wrote:

Is d as complex as C++?

On Tuesday, 14 December 2021 at 11:02:58 UTC, Ogi wrote:

ah right you mean for the built-in istring usage in the compiler it needs to be implemented.

I don't think it's such a big problem though, as the phobos implementation would also just be: (a little simplified)

auto text(istring...)(istring s) if (isIString!istring)
{
    return text(s[1 .. $]); // removes special __header, just concatenate rest
}

On Tuesday, 14 December 2021 at 11:14:03 UTC, zjh wrote:

Depends on what you want to do. You can write simpler code in D, often the syntax can be more compact in D.

However, C++ is adding features that make more convoluted C++-constructs unnecessary, but as a programmer you have to figure out what to not use since almost nothing is removed from C++. So it is hard for beginners to figure out what not to do, and what to do.

D is also increasing in complexity over time, often times I think that is because shortcuts are taken in the design and implementation.

The evolution of C++ is driven by the spec and not the implementation, so some features makes it into C++ that greatly improves the language even though some compilers have to be changed quite a bit.

But evolution in C++ moves in many directions, because it is designed by working-groups of different people. So it does not present a homogeneous "philosophy".

It would be much easier for D to work towards a homogeneous whole, but it has to be a conscious strategy because one can easily be tempted to fan out in all kinds of directions (by demands and DIPs etc).