D Language Foundation July 2023 Monthly Meeting Summary

harakim harakim at gmail.com
Wed Aug 16 03:18:27 UTC 2023


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.



More information about the Digitalmars-d-announce mailing list