On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:
> On Friday, 7 July 2023 at 09:35:14 UTC, Paolo Invernizzi wrote:
>>
>> I respectfully disagree, and prefer to keep going on with the current deprecation and cleanup policy: Scott Meyers' DConf 2014 keynote all the way down.
>
> +1
>
> I've always agreed with the deprecation in the end, even complex numbers.
> alias this was a relatively bad idea, even if an iconic feature.
> I don't remember people from outside the community being impressed by alias this.
> We have the right to backtrack on bad ideas instead of keeping them forever.
> The __traits changed feature was aout fixing an incorrect behaviour. It took 10 min to fix.
> The current deprecation system is very good.

I agree with these two messages.

On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:

> I don't remember people from outside the community being impressed by alias this.
> We have the right to backtrack on bad ideas instead of keeping them forever.

I don't know why anybody should be impressed, but Zig and Jai, the two closest competitors of D, both have a generalized version of 'alias this' ('usingnamespace' and 'using', respectively).

On Friday, 7 July 2023 at 22:41:38 UTC, Walter Bright wrote:
> The problem has a lot to do with people wanting to use 3rd party libraries, and it being impractical to upgrade those libraries when the maintainer of those libraries is no longer active. If a user's project depends on several such libraries, it places an undue burden on the user.

The third party import is the biggest pain, and compiler versions/deprecations add to it. As another mentioned it is sort of a dub problem.

As a user of the third party library I want my code strict, but I just want the third party to build as it was written. This has two main implication, does the compiler I'm using even know about the features the library uses, and if the library author instructed the compiler to be strict (I don't care)

If the library is built with a newer compiler version their isn't much to be done but upgrade the compiler. This has the implications where I would now want to compile my code without strictness (hopefully for a short period).

If the compiler has removed features then the library can't be built. This is were keeping functionality is beneficial.

If the compiler depricates functionality then I don't want to hear about. Though it would be good to know "library x is using deprecated functionality". This is where the compiler and dub need to work together. Dub can build my code with strict error and the the compiler provides a flag dub uses to build the third party libraries.

On Friday, 7 July 2023 at 12:34:50 UTC, Hipreme wrote:
> The problem right now, from my POV, is that people such as Grim is using dub dependencies. What that generates is that by the default functionality being showing the deprecation messages is that we need to modify unmaintained 3rd party code. How we use 3rd party code right now? DUB. The problem is that dub doesn't have a flag for keeping 3rd party code shut. So, in MY VIEW, dub should be the one to address that problem, not the D compiler itself.

I don't know how dub would address this problem by itself, but this is the number one issue that keeps me from using D as my primary personal language. And I agree that it's third party libraries that are an issue. I mean I have some old D1 code using Tango, but other than that, I do not have issues upgrading my own code. I don't like that it breaks, but if it were only my code that broke, I would use it as my primary language for personal projects.

After some discussion with Adam a few years ago, I heavily limited the libraries I use and I don't have this issue nearly as much anymore, but what it means is I am less likely to reach for D on a project, especially for something like a game where I would need third party libraries. And when I'm far more familiar with 3 other languages and tool chains, I don't reach for it for many of the 1-hour projects either. Although, I did do the timed programming course for a new job in D. :D

In short, if I could count on libraries the same as I do in C# and Java and, to a lesser extent, C, I wouldn't associate "new project in D" and "will take forever" in my mind and I would start by trying to make it work in D, like I used to.