Evolving the D Language

[Hipreme]

On Friday, 7 July 2023 at 03:14:38 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> I suspect that we kinda have it a little backwards.
>
> Keep it strict by default, but allow more code to pass if 
> desired.
>
> This is how a build manager like dub should operate.
>
> Part of the goal here is to make sure people don't go round 
> using undesirable features by accident.
>
> Also we should probably have the ability to turn on only a 
> subset of the features based upon version. That way you can 
> only accidentally add behavior that you already know about and 
> not have infinite possibilities going forward.
>
>
>
> And for the record I still want hex strings to come back. They 
> were incredibly useful with no good alternatives when we talk 
> about large tables of data being described.

There is 2 views to that side:

1: People doing their project and maintaining only their project.
2: People doing their project that has dub dependencies.


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.

One can see here that mostly people that disagreed with Walter's 
proposal is people which maintain all their own code. But that is 
obvious, since we're actively maintaining all of our dependencies 
basically. But thinking on a new user, what happens when they 
don't want to deal with 3rd party code or things feel like just 
out of control? It is not everyone that wants to fork something 
and use the forked version and start maintaining it.


On the `alias this` functionality, I think Walter is correct into 
saying that "we were wrong into deprecate this functionality 
without giving something to replace". `Alias this` is not 
incredible, but we have no reason to simply remove from the 
language without any kind of replacement.


But this is a long standing problem with dub that should be 
fixed: How global flags will behave or even having them: 
modifying `DFLAGS` environment variable is a hassle since it 
involves one command more, and most of the time it is not easily 
portable. Hipreme Engine has solved that problem by having 
something that runs before everything (and controls) , but dub 
itself hasn't solved. A good example of flags is the 
link-defaultlib-shared, -boundscheck and other things that 
changes how the language works somehow.

Warnings and deprecations aren't that different, so, I think dub 
should have a better way to manage 3rd party code. Also, seeing a 
lot of deprecation warnings as default for beginners is quite bad 
since they will be more discouraged to use its library and then 
someone will reinvent the wheel not because they're willing to do 
it for study, but because they will feel that it's NECESSARY.