Thread overview
ImportC shows the way to D3?
Jun 20
claptrap
Jun 20
bauss
Jun 20
claptrap
Jun 20
IGotD-
Jun 20
forkit
Jun 20
claptrap
June 20

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?

June 20

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

>

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?

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.

June 20

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

>

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?

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.

June 20
On Monday, 20 June 2022 at 08:26:35 UTC, IGotD- 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.

+1

Finally, a vision of how to move D in the forward direction!

Personally ;-) .. for D3, I'd start the 'breaking changes' by ensuring the language provides support for a proper class type (rather that Walter's interpretation of it), and, one that can be checked by the compiler.

i.e private means private!

Add an internal or something, so the default in a compilation unit (a module) is internal. You get the same thing as you currently have. Just make sure you have the option to declare a member private, and override that default.

I'd also set up a new offical organisational mandate, to ensure nobody, not even Walter, can arbitrarily add something to the language or the compiler, on a whim. Anyone that fails to comply, is booted out!

Then, and only then, will I consider using D again.

June 20

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

>

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?

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.

June 20

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

>

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

>

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?

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.

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?

June 20

On Monday, 20 June 2022 at 08:46:25 UTC, Ola Fosheim Grøstad 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.

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.

June 21

On Monday, 20 June 2022 at 23:29:04 UTC, claptrap 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.

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.