I'm able to report on a couple of decisions that we reached over the past two planning meetings.

Bugzilla to GitHub migration

The update on this is likely to result in quite a bit of discussion, so I've put it in a separate thread.

Deprecation policy

Deprecating alias this in classes was a mistake. Walter proposed that we revert it, and everyone got on board.

We also agreed with Walter's proposal to review other recent deprecations to determine if they were inappropriate or have caused unintended problems and, if so, examine if they can be reverted without causing new problems.

Going forward, we're going to take a much more conservative stance on deprecations:

• nothing should be deprecated unless there's a very compelling reason ("this feature was a mistake and people shouldn't be using it" is not a compelling reason)
• every deprecation should have a clear path for migration, automated if possible
• the person implementing a deprecation will be responsible for updating projects that trigger it in our BuildKite tests

Down the road, we'll need to decide on a better path for evolving the language. Atila thinks "editions" or "epochs" are the way to go, as he has mentioned in a couple of DConf talks. But that's for a future discussion. For now, we're still focused on stabilization.

Upcoming meetings

We've got a quarterly meeting with industry reps on July 7. Reps from Ahrefs and Decard will be joining us for the first time.

Our next monthly meeting is happening on July 14th.

Or next planning session is slotted for July 21st.

I'll have the summary for the June monthly meeting finished in a few days. You can usually see the bigger tasks I'm currently working on in the Strengthen the Community project on our GitHub projects page. I try to keep the notes on each in-progress task up to date.

On Tuesday, 4 July 2023 at 11:08:02 UTC, Mike Parker wrote:

I mean, only a slight step beyond that is "this feature is the cause of people creating bugs." What is a compelling reason?

For instance, I got alias Nullable.get this deprecated and later removed. I'm extremely glad that source of bugs is gone and would be upset if it was reverted.

What about things that are straight up bugs that contradict the spec? For instance, you used to be able to access a private function if it was overloaded with a public function that came after. Should we write that in the spec? Or should we just silently do the wrong thing?

(I don't agree with this policy, you can probably tell. :P)

Apropos, how do I get projects in the Buildkite suite?

On Tuesday, 4 July 2023 at 11:08:02 UTC, Mike Parker wrote:

100% agree, deprecation and breaking changes are needed to cleanup past mistakes, but proper migration path should ALWAYS be included to avoid that kind of issues

Also, for the love of god

https://github.com/dlang/dub/issues/2617 - "Get rid of deprecate warnings"
https://github.com/dlang-community/DCD/issues/722 - "Get rid of deprecate warnings"

I got ignored months ago for asking to clean up and fix ton of deprecation warnings

This should NEVER happen on projects that are hosted on official repos

If the head is careless, how do you expect everyone else to care?

On Tuesday, 4 July 2023 at 13:25:06 UTC, FeepingCreature wrote:

I can't speculate. It will have to be on a case-by-case basis.

You can add it in the CI repository, like so:

https://github.com/dlang/ci/commit/05df6423c2a78a4e410030b793e1e31e7ab1ed73

Or submit an issue for it there, or ask Razvan or Dennis.

On Tuesday, 4 July 2023 at 11:08:02 UTC, Mike Parker wrote:

You can really do weird stuff with alias this and people took advantage of it. Removing it would also remove the possibility to do these tricks without any alternative.

Removing alias is a typical D3 thing to consider. The whole deal with alias this and mixin composition should be reviewed and improved for D3. While mixin templates works fine, I'm not that keen on the syntax as it forces you to make a mixin template rather than a struct and a struct is better because you can reuse it in a number of different ways.

alias this is such an entrenched and iconic D feature now, I would almost go the other way, also use it for composition for syntax cohesiveness.

On Tuesday, 4 July 2023 at 13:25:06 UTC, FeepingCreature wrote:

Thanks, me too. For that there was a simple migration path. I think the level of breakage has to be outweighed by the benefits of the change. Accidental bugs can be much more costly than having to add .get in a few places.

For that example, it seems clear the user's code was at fault if it relied on accessing a private function. Though occasionally the spec may be wrong in some aspect - the solution may depend on how people understand the feature to work.