Proof of concept for v2 - NO duplication, NO `static if` hell, NO difficulty with interoperability

[Ola Fosheim Grøstad]

On Monday, 1 November 2021 at 19:05:56 UTC, bachmeier wrote:
> Maybe I'm not understanding, but if V1 includes, say, 
> std.range.primitives, you would know you could always rely on 
> everything in it to work exactly the same way for the next 50 
> years. V2 would include the first stab at std.range.interfaces, 
> V3 would include a different version of std.range.interfaces

So, there may be many issues here. One obvious one would be 
template bloat.

A worse one is if you use a database library with a runtime that 
is V2, then you use two packages, one that uses V1 of the 
database library and another that uses V2 of the database 
library. As a result you try to inject V1 objects into a V2 
database and that cannot work, but having two separate database 
instances may also don't work.

Then you also have the issue of compiler compatibility. Will V1 
work with all future versions of compilers? If I have written an 
application for a customer, and he 2 years later wants to have a 
tiny feature added, that is basically just bolting on a package 
that depends on V2, but that package also uses new language 
features. Will it compile? For how many years will V1 remain 
supported and tested?

In general when updating a product you usually want to upgrade to 
the latest version of the compiler and libraries, to get 
bug-fixes. The more expensive that upgrade becomes, the less 
appealing the development environment becomes.

A better strategy is to automatically rewrite old code to new 
code through a transform. Like, with Angular, I run an 
(imperfect) transform that upgrades to the latest version. So I 
only have to do minimal work. Then I can add new features to the 
product using the latest feature set. At the very least a 
transform could inject TODO-comments telling you what to look out 
for. Go also provides similar tools I think (I don't recall)?