On Tuesday, 25 July 2023 at 16:51:04 UTC, H. S. Teoh wrote:
> In compiler terms, this just means that the compiler has to (1) understand that it's dealing with code meant for an older version of the language, and (2) based on that knowledge adapt the way it processes the code in a way that preserves its original meaning.
That's an interesting comparison to older languages. I agree if you can do 1 and 2 then the problem wouldn't exist. I have doubts about whether people would do (1), although it could be done retroactively as needed, maybe even in an automated fashion. So that could work. Then there is (2). Would there be 104 code paths (for ex, 1 for each version) in the compiler? That seems like it would be super complicated.

> Something along these lines has to be done, otherwise we're never gonna move forward.  The ecosystem is just gonna stagnate because the more the language advances, the more old code and old libraries will stop compiling.

This is definitely true. I worked a job where we would sell a lot but our software was so bad, we would lose more customers than we gained. I hadn't really thought of it like that but I do feel like I find fewer tools and native libraries than I used to.

I think it would be reasonable for people to keep multiple compilers around. Maybe someone could be expected to keep each LTS version around. I don't know how much that would solve though since there would still be all the incremental versions. I'm not convinced the version thing is practical yet, but it would solve the problem. Do you think it would be practical to have a single compiler managing 100s of versions of the language?

On Wed, Jul 26, 2023 at 04:27:24AM +0000, harakim via Digitalmars-d wrote:
> On Tuesday, 25 July 2023 at 16:51:04 UTC, H. S. Teoh wrote:
> > In compiler terms, this just means that the compiler has to (1) understand that it's dealing with code meant for an older version of the language, and (2) based on that knowledge adapt the way it processes the code in a way that preserves its original meaning.
>
> That's an interesting comparison to older languages. I agree if you can do 1 and 2 then the problem wouldn't exist. I have doubts about whether people would do (1), although it could be done retroactively as needed, maybe even in an automated fashion. So that could work.

This one is easy: introduce a version declaration at the top of every module, say a `version = "2.105.0";`, or something alongside the module declaration, like `module my.module version("2.105.0");`.  All older code that don't have this declaration will be assumed to be written for some fixed baseline version, say the latest version before this scheme is implemented in the compiler.  Then going forward, all unmarked code will be pinned at that version, and to get newer features you'd introduce the version declaration to your module, thereby ensuring that it will be properly marked going forward.


> Then there is (2). Would there be 104 code paths (for ex, 1 for each
> version) in the compiler? That seems like it would be super
> complicated.

It's impractical to retroactively do this for previous releases. Just set the current release (or whatever release this scheme will start in) as the baseline, and have each new feature guarded by an appropriate version condition, so that the old code path will continue to run if the current module isn't versioned for a release that includes the new feature.  We don't have to keep 104 copies of the compiler code around for this, that'd be an unmaintainable mess.


> > Something along these lines has to be done, otherwise we're never gonna move forward.  The ecosystem is just gonna stagnate because the more the language advances, the more old code and old libraries will stop compiling.
> 
> This is definitely true. I worked a job where we would sell a lot but our software was so bad, we would lose more customers than we gained. I hadn't really thought of it like that but I do feel like I find fewer tools and native libraries than I used to.
> 
> I think it would be reasonable for people to keep multiple compilers around.  Maybe someone could be expected to keep each LTS version around. I don't know how much that would solve though since there would still be all the incremental versions. I'm not convinced the version thing is practical yet, but it would solve the problem. Do you think it would be practical to have a single compiler managing 100s of versions of the language?

It will make the compiler more complex to maintain, certainly.  But *something* has to be done... otherwise nothing is going to change and the D ecosystem is going to remain small forever.


T

-- 
Once bitten, twice cry...

On 7/24/2023 12:24 PM, max haughton wrote:
> For deprecations that are either syntactic or a direct substitution, the compiler should just fix it for you - clang and gcc (to a lesser extent) can both do this, e.g. the body=>do change - regardless of the justification the compiler should just parse it and fix it (or emit a diff, etc etc).

The ones we can unambiguously fix are the ones we can accept anyway.

On 7/25/2023 3:21 AM, Paolo Invernizzi wrote:
> I understand your point, but to me the need to explain a programmer, "yes dude, 'in ref' was an ancient way of doing 'in', just keep ALSO that in mind" is a strategic error. Stepping back from the current deprecation mechanics is a pity.

`in ref` is now accepted without comment. It doesn't hurt anything.

On 7/25/2023 9:51 AM, H. S. Teoh wrote:
> The only solution, to avoid having to do a massive rewrite of 90% of D's
> entire ecosystem every time there's a language change, is to have the
> compiler understand old code and compile old code in the way it was
> supposed to be compiled years ago.

As much as we can, that's the way we're going to do it moving forward.

In addition, we're considering some sort of annotation in the source code saying which "edition" of D the module conforms to.

On Wed, Jul 26, 2023 at 12:54:02PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/25/2023 9:51 AM, H. S. Teoh wrote:
> > The only solution, to avoid having to do a massive rewrite of 90% of D's entire ecosystem every time there's a language change, is to have the compiler understand old code and compile old code in the way it was supposed to be compiled years ago.
> 
> As much as we can, that's the way we're going to do it moving forward.

Good to hear!


> In addition, we're considering some sort of annotation in the source code saying which "edition" of D the module conforms to.

Yes, that's exactly what I have in mind.


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney

On Wednesday, 26 July 2023 at 19:54:02 UTC, Walter Bright wrote:
> On 7/25/2023 9:51 AM, H. S. Teoh wrote:
>> The only solution, to avoid having to do a massive rewrite of 90% of D's
>> entire ecosystem every time there's a language change, is to have the
>> compiler understand old code and compile old code in the way it was
>> supposed to be compiled years ago.
>
> As much as we can, that's the way we're going to do it moving forward.
>
> In addition, we're considering some sort of annotation in the source code saying which "edition" of D the module conforms to.

Not sure if you're familiar with Circle, but it looks like that's what they are trying to do.

https://github.com/seanbaxter/circle/blob/master/new-circle/README.md#versioning-with-feature-directives

Started watching this
https://www.youtube.com/watch?v=x7fxeNqSK2k

On Wednesday, 26 July 2023 at 19:47:55 UTC, Walter Bright wrote:
> On 7/24/2023 12:24 PM, max haughton wrote:
>> For deprecations that are either syntactic or a direct substitution, the compiler should just fix it for you - clang and gcc (to a lesser extent) can both do this, e.g. the body=>do change - regardless of the justification the compiler should just parse it and fix it (or emit a diff, etc etc).
>
> The ones we can unambiguously fix are the ones we can accept anyway.

Shall we accept C-style casts anyway?

Practicality aside, D is also supposed to have some taste.