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.
