Evolving the D Language

[Jesse Phillips]

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.