Which language constructs could be done as a library if we accept some breaking changes?
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Wed Dec 1 09:13:57 UTC 2021
On Tuesday, 30 November 2021 at 19:56:01 UTC, Guillaume Piolat
wrote:
> On Tuesday, 30 November 2021 at 14:46:59 UTC, Ola Fosheim
> Grøstad wrote:
>>
>> There should absolutely be an upgrade path
>
> Such as with -preview/-revert then?
This is possible:
1. -preview-d3-feature-X on the D2 side
2. -emulate-d2-feature-Y on the D3 side for common "deprecated"
features.
3. Allow subsystems compiled with both D2 and D3 to be combined
using high level intermediate representation (HIR) so that you
can transition one subsystem at a time from D2 to D3. Although,
you might have to replicate some templates on both sides because
I doubt that "static if" is suitable for HIR.
You have to decide case-by-case what is worthwhile. It has to be
based on what existing code-authors find difficult.
>> For files ending in ".d" emulate most of the current
>> behaviour. For files ending in ".d3" provide the full cleanup.
>
> Can you give an example of breaking changes that this .d3 trick
> allows, that cannot be covered by -preview/-revert?
If you create a new modular frontend and follow a clean spec,
then you will get many differences all at once. Anything that
depends on "does-this-compile-traits" could break even if you try
to emulate DMD. The alternative is to reimplement all quirks of
the current frontend and that could have a negative complexity
impact and a development time impact, basically not making it
worthwhile.
All changes that are cleaning up language semantics, can
potentially break things such as traits. When you move something
to a library or change things you will affect those that do
"shoehorn tricks" with the language.
You should probably only aim for ease of transition for people
who write good code. People who rely on trickery are very costly
to support.
Anyway, «D3» is inevitable if the current compiler is difficult
to evolve, maybe it already «exists» in the shape of another
language with no affiliation to D.
More information about the Digitalmars-d
mailing list