On Monday, 21 September 2020 at 20:49:00 UTC, Walter Bright wrote:
> On 9/21/2020 7:08 AM, Paul Backus wrote:
>> My guess is that allowing a struct to inherit from another struct would cover around 80% of the use-cases for `alias this`.
>
> The use case not covered by it is forwarding to a function.

Since I didn't have a clear idea of how common this was, I decided to do a quick grep through Phobos to see how many `alias this` declarations forwarded to a member variable vs. a function. Excluding unit-test code, my results were:

Variable: 15
Function: 14

So, pretty much exactly 50/50--my guess was totally off.

While C++ names things by the year, the compilers don't actually follow this schedule. Compilers have varying levels of implementing the new standards, some years before, some years after.

Once something is implemented, I don't see the advantage of delaying deployment of it, possibly for years, in order to meet some arbitrary milepost.

I had the same idea as you did, and ran aground for the same reason.

On 9/21/20 7:15 AM, Mike Parker wrote:
> Our current release schedule, despite being divided into "major" and "patch" releases, is just a string of incremental releases every two months. There's nothing to differentiate one major release from another -- it's all D2 -- and some may feel pressure to update to the latest major compiler release as often as possible, risking the headaches of breakage, regressions, and with the remedy of only one patch release before it's time to do it again.
> 
> This situation spawns discussions of D3, std.v2, and now this.
> 
> Watching what C++, and especially Java, are doing these days, I feel like our approach is antiquated. What we need is an obvious way to delineate the feature set of any version of both the language and the standard library, and create a path that allows for a more leisurely, less risky style of updates.
> 
...

> My 2 cents.

All excellent comments. It is worth bringing up Rust here, which also uses year-edition as a demarcation point, but does so slightly differently than C++.

Interestingly, new features are delivered continuously (much as we do with D), until such time that a new "edition" is frozen such that the feature set at that time is designated "2018" (or whatever) and is a well-defined point-in-time that you may use safely in the future. If you want new features, you can use them but you must use stable, beta, or nightly.

https://doc.rust-lang.org/book/appendix-05-editions.html
https://doc.rust-lang.org/book/appendix-07-nightly-rust.html

I could see "D 2021 edition" :)

On Monday, 21 September 2020 at 23:57:17 UTC, Walter Bright wrote:
> While C++ names things by the year, the compilers don't actually follow this schedule. Compilers have varying levels of implementing the new standards, some years before, some years after.

Doesn't have to be thr year. Java does just fine with sequential whole numbers. The point is that I can't tell you which D feature came in which release without digging through the changelog, but though I don't even use Java anymore I know that switch expressions came in Java 12 or 13.


>
> Once something is implemented, I don't see the advantage of delaying deployment of it, possibly for years, in order to meet some arbitrary milepost.

We have milestone releases already (2.094, 2.095). What we don't have is extended patch support or any ckear way to delineate the language versions. I mean, D 2.094 is a different languge than D 2.074. How many people can say how they differ?

And if I want to upgrade from 2.094 to 2.095, but the new version introduces a regression that blocks me, that regression might not be fixed until 2.098. Now in order to upgrade I need to deal with the changes and possible regressions in multiple milestone realeases because there's no long-term patch support for 2.095. This is not a hypothetical situation. It has happened to companies using D in production.

On Monday, 21 September 2020 at 23:57:17 UTC, Walter Bright wrote:
> Once something is implemented, I don't see the advantage of delaying deployment of it, possibly for years, in order to meet some arbitrary milepost.

A lot of c++ features get implemented before the spec is finalized. You can use the features by specifying a specific version. For anyone that wants bleeding edge they can access the new features. Those new features tend to introduce regressions and are buggy. The bugs that get ironed out early on don't follow deprecation paths as the feature is still new and isn't used that wildly, so breaking changes are let through more easily in these cases. Discouraging investing in using the feature even if it is "implemented".

On Tuesday, 22 September 2020 at 03:19:43 UTC, Avrina wrote:
> On Monday, 21 September 2020 at 23:57:17 UTC, Walter Bright wrote:
>> Once something is implemented, I don't see the advantage of delaying deployment of it, possibly for years, in order to meet some arbitrary milepost.
>
> A lot of c++ features get implemented before the spec is finalized. You can use the features by specifying a specific version. For anyone that wants bleeding edge they can access the new features. Those new features tend to introduce regressions and are buggy. The bugs that get ironed out early on don't follow deprecation paths as the feature is still new and isn't used that wildly, so breaking changes are let through more easily in these cases. Discouraging investing in using the feature even if it is "implemented".

That's to say if you want how D is developed now you'd just use -spec=d2.xy and it'll enable be at the bleeding edge. What'd this introduce is a way for people that want and need backwards co.patibility to have it.

On Tuesday, 22 September 2020 at 03:24:32 UTC, Avrina wrote:
>
> That's to say if you want how D is developed now you'd just use -spec=d2.xy and it'll enable be at the bleeding edge. What'd this introduce is a way for people that want and need backwards co.patibility to have it.

We have `-preview` for this.

On 9/21/2020 6:08 PM, Mike Parker wrote:> D 2.094 is a different languge than D 2.074. How many people can say how > they differ?
I can't say, either, without looking at the changelog. But does it matter? If a particular feature is of interest, can't the changelog suffice?


> And if I want to upgrade from 2.094 to 2.095, but the new version introduces a regression that blocks me, that regression might not be fixed until 2.098. Now in order to upgrade I need to deal with the changes and possible regressions in multiple milestone realeases because there's no long-term patch support for 2.095.
I agree that no long-term patch support is a problem. But it's mainly the result of our team being small, not having a different release scheme. There's nothing really preventing a regression fix from going back into any particular release except someone actually doing it.

Needing patch support for various versions could be an ideal thing that companies that need it can supply funding for.

On Tuesday, 22 September 2020 at 03:49:22 UTC, Mathias LANG wrote:
> On Tuesday, 22 September 2020 at 03:24:32 UTC, Avrina wrote:
>>
>> That's to say if you want how D is developed now you'd just use -spec=d2.xy and it'll enable be at the bleeding edge. What'd this introduce is a way for people that want and need backwards co.patibility to have it.
>
> We have `-preview` for this.

Doesn't solve the problems Mike outlined. I've experienced the same problems, a regression preventing me from using using a new version of DMD, while the new version has a bug fix I needed.