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.
