Addressing deprecations, I think deprecation messages are good if
we are writing code that will break things. I would be surprised
if anyone wanted these off by default for *new* code they write.
I can see a case for suppressing new deprecations in existing
code so you don't lose the warns/errors in the noise and so you
can stop the bleeding by catching deprecations in new code. I
think it would be interesting to see what the demand is for this.
If it is enough demand (although I assume still not a lot) I
think the compiler could actually be changed to do a shoddy job
of this fairly easily, so long as there is a common function
called to output a warn/error/deprecation. It would involve 2
changes to that/those functions: 1. if they want to suppress all
existing warn|error|deprecation, output to the file instead. 2.
If they specified a file of suppressions, check that before
output. I feel like this is a temporary solution to a temporary
problem that probably doesn't affect a lot of people.
I know this idea will not be popular, but I think deprecations
should be on by default and this solution as a temporary measure
would be better than turning off deprecations by default. More
feedback would be needed to determine what the extent and
severity of this deprecation message issue is.
The DIP 1000 deprecations are different because they probably
should not exist based on the discussion. It is no fault of the
developers and there is nothing reasonable they should do.
On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:
He said he was aware of discussions of how rapid our releases
were and that people wanted to slow down, but he didn't think
making a decision based on a forum post would be appropriate,
and this meeting wasn't the right forum to decide whether we
should change our release schedule.
As one of the strongest proponents of backwards compatibility, I
agree that I would like a sustainable solution to this problem.
The language has to change over time and breaking changes will
have to happen. If the solution is not sustainable, it will get
pushed aside. I think the issue is making the changes affect
users an acceptable amount, not all or nothing.
I have been thinking off and on why this is such a large problem
in D for me and has barely even registered as an issue in other
languages. Four of the reasons that come up each time are:
1. D is still in the hobby phase for me. I put my projects down
for longer periods of time.
2. I compile all my D dependencies from source. Other than
Javascript*, I use pre-compiled libraries for projects in all
other languages.
3. In other languages, there are enough developers that a few
dozen or hundred well-maintained libraries exist to cover the
basics.
4. D seems to change here and there where other languages have
clearly defined roadmaps.
I think 1, 3 and probably 4 will become non-issues if D becomes a
popular language.
For now, I do wonder why we can't change from building all
dependencies to just including libraries. If that binary
interface was stable, the language could change quite a bit and
maybe it's less of an issue. There is always the option to build
from source, but if third parties included the compiled library,
it could keep working long after it stopped compiling.
Another option would be having the library maintainer version
their library and the compiler compile old versions to link.
Again, this is based off the assumption that maintaining the
backwards compatibility of a binary interface is simpler than
maintaining it in the source.
That wouldn't help with user's immediate projects not compiling,
but with an upgrade tool or guide, that would be less of an issue
because you usually know the code. It could also be solved by LTS
versions or just using an old compiler version. In any case, I
see any solution to stability as a temporary solution to a
problem that will not be as big in 5 or 10 years.
*Javascript is an all around pile of garbage and it also rarely
changes in a significant way. Also, some python libraries I use
probably come as source.
