This is why I don't use D.

[Neia Neutuladh]

On Wednesday, 5 September 2018 at 04:32:18 UTC, SrMordred wrote:
> Wouldn´t be interesting to specify the compiler version on 
> dub.json?
> (I think ruby uses this idea)

Ruby 1.8 stuck around for four years before Ruby 1.9 came out. 
Then it was six years until Ruby 2.0 came out. These days, 
there's an annual release, but the magnitude of changes is also 
pretty small.

Compare with DMD over the past year. (Just one year!) opDot was 
deprecated, C-style array declarations were removed, opDispatch 
works differently with `with` statements, arithmetic with 
pointers of different types was deprecated, comma expressions no 
longer yield a value, `delete` was deprecated, hex string 
literals were deprecated, class allocators were deprecated, 
certain types of postblit operators were deprecated, some 
operations on `shared` variables were deprecated, declarations in 
switch-case statements can't be used in other case blocks 
anymore, `catch` statements have to declare something they catch 
now, you can't compare values from different enum types anymore...

That's not all the breaking language changes in the past year. 
And it's just one year. (I'm cheating a bit by counting both 
deprecations and lapsed deprecation periods, but still.)

D can't use semantic versioning because nearly every release has 
breaking changes. Most of them won't affect your code in 
particular, but once you start using a bunch of libraries, it's 
going to be painful.

So how does this work with your library and depending on a 
specific range of language versions? You test with whatever 
compiler you normally use, and if you're super conscientious, you 
might test out a few other versions. So in order to stay 
up-to-date with new compiler releases, you need to re-test your 
library, update the supported-versions flag, and tag a new 
release every time there's a compiler change.

Fortunately, this can be automated, as long as you have automated 
testing.