So if D can "import" C code then could the same mechanism be used to move to D3? Have the compiler compile D2 and D3 code to the same AST?

Disclaimer : I dont know exactly how ImportC works but it sounds like it compiles C code into the same AST that D code uses. Then its all compiled the same.

yeah I know D3... but it could be a way to introduce breaking changes without too much pain?

Surely i cant be the only person who's thought of this?

On Monday, 20 June 2022 at 08:05:38 UTC, claptrap wrote:

The only problem I see is how will you differentiate a module from D2 with a module from D3?

At least how would you do that without having to specify that for each source file that it belongs to either D2 or D3, because I can't really seeing it being automated easily.

On Monday, 20 June 2022 at 08:05:38 UTC, claptrap wrote:

I think you come with a good suggestion and we need D3 as a more disruptive platform in order move the language forward. What you suggest is similar to C++ with version switches (ex. -std=c++20).

I suggest an alternative approach than with the DIPs we have today. With D3 we have a lower threshold what we can add. Depending on how successful a new feature is, the feature can be considered to be migrated to D2 so we can have a "migration DIP".

Right now the project is stale which is understandable as D2 should be somewhat stable. We need D3.

On Monday, 20 June 2022 at 08:05:38 UTC, claptrap wrote:

Compiling to the same AST does not allow you to change semantics without ending up with more complex compiler internals. So you are limited to smaller semantic adjustments and syntax.

I've suggested somewhere else that if DMD implemented a high level IR between frontend and backend then you could compile D2 and D3 to the same high level IR.

But you still have to replicate templates in both your D2 and D3 code bases as you don't want to do D-style meta programming in the high level IR that sits before the backend. You also cannot just combine D3 with D2 templates when D2 is capable of introspection.

If fixing bugs and completing the semantics of D2 is time consuming, why would you make it even more difficult to achieve by merging D3 into the D2 frontend? Yes, this also applies to "import C". It was done at the wrong time. The internals should have been redesigned first to handle it gracefully.

On Monday, 20 June 2022 at 08:19:36 UTC, bauss wrote:

you'd have to manually differentiate, and do it in a way that existing code is unaffected, so mark D3 files with a different file extension, like .d3?

On Monday, 20 June 2022 at 08:46:25 UTC, Ola Fosheim Grøstad wrote:

Well if that's the case an experimental branch where the internals are redesigned, and if/when that's successful you work on D3, but you'd keep the current vanilla D2 branch as the main compiler until such time as the experimental/D3 one is ready for prime time.

On Monday, 20 June 2022 at 23:29:04 UTC, claptrap wrote:

Either that or start over from scratch (or using SDC) using the existing code base as an inspiration. Doable if you position D3.0 as having a smaller and more focused scope. I.e leave out all features that can be done with meta programming.