D Language Foundation July 2023 Quarterly Meeting Summary

[max haughton]

On Saturday, 29 July 2023 at 14:15:12 UTC, Mike Parker wrote:
> The quarterly meeting for July 2023 took place on the 7th at 
> 15:00 UTC and lasted just over 70 minutes.
>
> [...]

Most of the points raised about deprecations seem to be primarily 
about treatment of all the code identically — if you compile dub 
libraries should you see their deprecations by default? Maybe on 
the first go, but probably not of all of them in full detail (a 
summary is fine).

Should the compiler bend over backwards to keep old code working? 
I think it should, in a smart way at least, but some of the 
things we will deprecate and have (probably) deprecated have been 
misleading or dangerous so sometimes shouting about them is a 
good thing. Supporting features on a more granular level is not 
massively hard to do.

All of the information to make the compiler smarter in this 
regard is either available to it or available to be passed to it 
by dub.

I don't yet fully understand what -wo is actually supposed to do 
(n.b. -wo is a very un-lindy/unwise name, take a leaf from 
GCC/Iain's approach, they are read more than they are written by 
users), but some of this seems to be leading to their being no 
deprecation/removal of features at all, which seems to be 
completely at odds with the spirit expressed recently — are we 
not suppose to be simplifying D? We are not C++.

And again, most of the annoying deprecations come from dip1000 — 
people have been saying it longer than I've been using D, are 
saying it now, and will continue to say it: it's not ready yet. 
It's not aligned with want users want, and what good D code wants 
to be, theoretically and ergonomically — in its current form it's 
just an easy arbitrage for competing languages.


---

Shortened Gameplan: organize the messages into a tree of 
(sub)sets of deprecation messages, provide a report on a 
per-library with detail depending on some notion of priority & 
whether the active programmer actually wrote that code or not 
(i.e. I did not write vibe.d, I mostly don't care), then spit 
them out in full somewhere for when you actually want to fix them.