December 13, 2021

On Monday, 13 December 2021 at 16:59:47 UTC, Adam D Ruppe wrote:

>

On Monday, 13 December 2021 at 16:40:31 UTC, Ola Fosheim Grøstad wrote:

>

I would prefer something like sql"…", css"…" etc.

How would you implement those?

That really depends on what your philosophy is. I've given some hints above. What do you want to achieve?

  1. better IDE support?

  2. total control in metaprogramming for each application?

  3. types that are shared between libraries (E.g. multiple frameworks using the same sql-literal)

  4. solid error messages from the compiler without libraries having to go out of their way to provide it?

If you want 1, 3, 4 then you probably should consider using a validating grammar in the compiler. If you want 2, then you can make it a type like I suggested above.

December 14, 2021

On Monday, 13 December 2021 at 23:35:40 UTC, Ola Fosheim Grøstad wrote:

>

If you want 1, 3, 4 then you probably should consider using a validating grammar in the compiler. If you want 2, then you can make it a type like I suggested above.

The DIP covers all this and has an actual answer.

December 14, 2021

On Tuesday, 14 December 2021 at 00:04:40 UTC, Adam Ruppe wrote:

>

The DIP covers all this and has an actual answer.

No, the DIP is a hack. I've pointed to other answers and you are smart enough to figure it out, but you have no interest in making D more than a language for enthusiasts.

For D to be an alternative to C++ it has to clean up and provide stronger typing.

December 14, 2021

On Tuesday, 14 December 2021 at 08:04:30 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 14 December 2021 at 00:04:40 UTC, Adam Ruppe wrote:

>

The DIP covers all this and has an actual answer.

No, the DIP is a hack.
Summarizing earlier comments, I disagree.

>

I've pointed to other answers and you are smart enough to figure it out, but you have no interest in making D more than a language for enthusiasts.

This is a curious comment. Antonyms for "enthusiast" include: adversary, critic, detractor, ...

Given Adam's considerable assistance to beginners in Discord and elsewhere, perhaps more than anyone else in the forums, I find this a wildly inaccurate comment as well.

>

For D to be an alternative to C++ it has to clean up and provide stronger typing.

Factually, no. D is already an alternative to C++ for some of us. Could it be a stronger alternative to C++? Sure, but it is and can be much more than that.

December 14, 2021

On Tuesday, 14 December 2021 at 14:24:44 UTC, Bruce Carneal wrote:

>

Given Adam's considerable assistance to beginners in Discord and elsewhere, perhaps more than anyone else in the forums, I find this a wildly inaccurate comment as well.

He was dismissive when I pointed out that this DIP not be ideal for newbies, he took a pro-enthusiast stance. That's ok, but that is a pattern in the evolution of D that makes the language less accessible. It is driven by the most enthusiastic crowd.

>

Factually, no. D is already an alternative to C++ for some of us. Could it be a stronger alternative to C++? Sure, but it is and can be much more than that.

It is an alternative if you don't need frameworks, but in order to get enough people working with, to get a solid eco-system, you have to reach outside the enthusiast fold.

There is nothing wrong with a language for enthusiasts, by enthusiasts, but it is a fairly narrow segment.

D as a whole is gradually narrowing down into that enthusiasts' fold.

December 17, 2021

On Tuesday, 14 December 2021 at 14:49:42 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 14 December 2021 at 14:24:44 UTC, Bruce Carneal wrote:

>

Given Adam's considerable assistance to beginners in Discord and elsewhere, perhaps more than anyone else in the forums, I find this a wildly inaccurate comment as well.

He was dismissive when I pointed out that this DIP not be ideal for newbies,

DIP's are not supposed to be for newbies. They are destined at the language implementers and advanced users to detect issues and solutions to the problems. They are not tutorials and should not cater to beginners.

>

he took a pro-enthusiast stance. That's ok, but that is a pattern in the evolution of D that makes the language less accessible. It is driven by the most enthusiastic crowd.

Strange argument. It is like a car manufacturer would scold their engineers that their development plans cannot be read by an apprentice mechanic.

December 17, 2021

On Friday, 17 December 2021 at 09:42:30 UTC, Patrick Schluter wrote:

>

DIP's are not supposed to be for newbies. They are destined at the language implementers and advanced users to detect issues and solutions to the problems. They are not tutorials and should not cater to beginners.

I don't think he's referring to the DIP process, but rather what the DIP covered.

Meaning the language construct and implementation.

December 17, 2021

On Friday, 17 December 2021 at 10:14:32 UTC, bauss wrote:

>

On Friday, 17 December 2021 at 09:42:30 UTC, Patrick Schluter wrote:

>

DIP's are not supposed to be for newbies. They are destined at the language implementers and advanced users to detect issues and solutions to the problems. They are not tutorials and should not cater to beginners.

I don't think he's referring to the DIP process, but rather what the DIP covered.

Meaning the language construct and implementation.

This is a documentation issue. That the implementation of the DIP might not be easily understood by newbies is imho irrelevant. The skill of the users might be a factor for the usage of the feature, not how it is put in the language.

Look, Walter's initial proposition was much simpler and quite easier to understand. This proposition requires much higher skills to understand how it works (one needs to know what parameter tuples, templates, overloads etc.), yet Walter's proposition was a stinker (sorry for the language) because it opened the floodgate of substitution bugs, type mismatches and injection risks. Traps a newbie could easily fall into. On the new proposition, newbies might be stumped on certain behaviours (i.e. it's magic) but the language does the "right thing". If the "right thing" is a little bit more complicated, so be it.

December 17, 2021

On Wednesday, 8 December 2021 at 10:46:31 UTC, WebFreak001 wrote:

>

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated#compilation-of-interpolated-strings

>

Beginning with C# 10, when an interpolated string is used, the compiler checks if the interpolated string is assigned to a type that satisfies the interpolated string handler pattern

Usage example: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/interpolated-string-handler

What do you think of these extended interpolated string expressions? I think these would fit well into D, and could give some new motivation now that we have had our interpolated strings DIPs rejected once and withdrawn once.

It's fun how we discuss how we should do this while other have solved this years ago.

Just do what others do, then at a later stage we can "improve" it.

D will probably never get string interpolation tbh, we will just discuss various solutions, but no one will be chosen.

December 17, 2021

On Friday, 17 December 2021 at 12:14:16 UTC, Imperatorn wrote:

>

It's fun how we discuss how we should do this while other have solved this years ago.

Just do what others do, then at a later stage we can "improve" it.

D will probably never get string interpolation tbh, we will just discuss various solutions, but no one will be chosen.

Don't be ridiculous. When D gets string interpolation in 2078, it'll be better than any of the 2021 implementations in other languages.