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