On 7/26/2023 1:28 PM, jmh530 wrote:
> 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

Yeah, something along those lines.

On 7/26/2023 1:46 PM, max haughton wrote:
> Shall we accept C-style casts anyway?

I don't think we have without a warning since day 1.

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

Of course.

On Wednesday, 26 July 2023 at 18:15:18 UTC, H. S. Teoh wrote:
> 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.

What specific advantages would you get in requiring every file to have a version as opposed to a compiler flag that can be passed in via the build tool like dub? I feel like a project is usually worked on as a version. I don't know a lot about linking but it seems like you could build each dependency with its own version and link them with rare exceptions. That would make it easier to use and also to retrofit old projects you come across than manually updating every file.

If you think per file is the way to go, then what if instead of defaulting to say 2.105 forever, it defaulted to the latest LTS/major version. And then if you wanted to compile older stuff that no longer compiles, it could just use the old compiler. I don't think it would be a high bar to have people download multiple versions of the compiler. It could be included in the default download perhaps. I always have several JDKs and usually even a few versions of Visual Studio.

Also, I agree that this wouldn't make sense retroactively. I was thinking if we have 100 versions now, then one day we will probably have 100 more.

I appreciate you taking the time to walk me through this because it's giving me a lot of peace of mind and I think you're definitely on to something.

On Thursday, 27 July 2023 at 05:11:48 UTC, harakim wrote:
> On Wednesday, 26 July 2023 at 18:15:18 UTC, H. S. Teoh wrote:
>> 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.
>
> What specific advantages would you get in requiring every file to have a version as opposed to a compiler flag that can be passed in via the build tool like dub? I feel like a project is usually worked on as a version. I don't know a lot about linking but it seems like you could build each dependency with its own version and link them with rare exceptions. That would make it easier to use and also to retrofit old projects you come across than manually updating every file.
>
> [snip]

One potential advantage would be that it is more fine-grained. You could incrementally change your project on a file-by-file basis without doing everything at once. I don't have a good sense of how this would work with dependencies.

Also, if you check out the links I included previously, the idea in Circle is if you don't include a version, then it is just normal C++. The versions are completely opt-in. I think HS Teoh makes reference to this in his later discussion that his own idea of it is basically opt-in. I think that was one of my hang-ups when I first tried to understand his idea.

The other part of Circle that is interesting is that you don't have to specify everything in each file, you can have a separate file that says what features you want to use and then have the version statement (or whatever it is called in Circle) refer to that. So instead of having to change every single file when you want to make an adjustment, you could only change it in one place. If D went this route, then I think something similar would be important.

On Thu, Jul 27, 2023 at 05:11:48AM +0000, harakim via Digitalmars-d wrote:
> On Wednesday, 26 July 2023 at 18:15:18 UTC, H. S. Teoh wrote:
> > 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.
> 
> What specific advantages would you get in requiring every file to have a version as opposed to a compiler flag that can be passed in via the build tool like dub?

3rd party libraries.  Say your project depends on libraries A, B, C. Each of them could potentially be written for a different edition of the language, and your own code could also be for a different edition, so you'll have to compile with 4 different compilers.  Also, every time you add a new dependency you potentially have to install yet another compiler.  It's just not scalable, and needlessly confusing for newbies ("what, why do I need 10 different compilers just to compile my one test project?!").

Better just to have a single compiler to handle it all.


> I feel like a project is usually worked on as a version. I don't know a lot about linking but it seems like you could build each dependency with its own version and link them with rare exceptions.
[...]

Not really. Most D releases are ABI-incompatible, so you're liable to end up with lots of inscrutable linker errors and/or inscrutable runtime odd behaviours caused by incompatible ABIs if you try to link together objects compiled by different versions of the compiler.  Safer to use a single compiler to compile and link everything.


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!