Windows experience is atrocious

jmh530 john.michael.hall at gmail.com
Tue Jul 25 12:59:48 UTC 2023


On Tuesday, 25 July 2023 at 09:55:31 UTC, H. S. Teoh wrote:
> [snip]
>
> I'm actually in both camps, if that even makes sense. :-D
> [snip]

What you describe with respect to compatibility mode is opt-in on 
a per file basis, which might place an annoying burden on users. 
As opposed to something that works more globally, like dub 
toolchain requirements (though I'm not sure how that resolves the 
issue with respect to libraries you mention).

However, I'm sympathetic to the idea. For it to work however, it 
might end up making the compiler a little more complicated since 
it would need to be able to compiler previous versions of the D 
language (or force you to have multiple D compilers installed and 
just call them).

What if instead you paired that with something like the LTS ideas 
floating around. So the D equivalent of something like 
`-std=c++20`. One of the operational difficulties with the LTS 
idea is that you can just call some version of DMD the LTS, but 
that doesn't get you bug fixes from newer versions that you might 
want. You need people to actually implement them. However, if the 
LTS version is kept within the main compiler as a switch, then it 
is a little bit easier to keep it up to date with bug fixes.

It still would end up making the compiler (and work on the 
compiler) more complicated. If someone adds a new feature or some 
kind of breaking change, then they would need to maintain the old 
behavior in a version statement. Normal bug fixes could be 
applied without this, so it would impact both versions.

It would also be different from C/C++ where you have to opt-in to 
the newer version. In D, you would be opting in to the older 
version (unless something were changed with how we think about 
releases).


More information about the Digitalmars-d mailing list