www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Planning Update June 23 & 30 -- Bugzilla to GitHub; Deprecations

reply Mike Parker <aldacron gmail.com> writes:
I'm able to report on a couple of decisions that we reached over 
the past two planning meetings.



The update on this is likely to result in quite a bit of 
discussion, so I've [put it in a separate 
thread](https://forum.dlang.org/post/kttzxwbbvdpzxlmoyvyo forum.dlang.org).



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.



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](https://github.com/orgs/dlang/projects/24/views/1?layout=board) on our
GitHub projects page. I try to keep the notes on each in-progress task up to
date.
Jul 04 2023
next sibling parent user456 <user456 123.de> writes:
On Tuesday, 4 July 2023 at 11:08:02 UTC, Mike Parker wrote:

 I'm able to report on a couple of decisions that we reached 
 [...]
 * 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


There's a TZ problem here. The first PRs were submited before 
your annoucement and lead to confusion:

e.g 
https://github.com/dlang/dmd/pull/15379#issuecomment-1619628624

or quote from IRC


 [08:56] * DFeed [GitHub] Walter‎Bright opened dmd pull request 

 https://github.com/dlang/dmd/pull/15380
[08:57] <Herringway> oh no what is walter doing now
[09:02] <Herringway> did I waste my time keeping up with 
deprecations...?
[09:05] <-- opticron (~opticron 136.53.58.220) a quitté ce 
serveur (Server closed connection).
[09:06] --> opticron (~opticron 136.53.58.220) a rejoint ce 
canal.
[09:13] <opDispatch> yeah, earlier I was about to drop a comment 
about the tooling but actually dparse still supports body 
apparently


so... for a few hours people thought it was a Walter's fad and 
not a well defined direction.
Jul 04 2023
prev sibling next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 4 July 2023 at 11:08:02 UTC, Mike Parker wrote:

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



 The update on this is likely to result in quite a bit of 
 discussion, so I've [put it in a separate 
 thread](https://forum.dlang.org/post/kttzxwbbvdpzxlmoyvyo forum.dlang.org).



 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)


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)


 * 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


Apropos, how do I get projects in the Buildkite suite?
Jul 04 2023
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 4 July 2023 at 13:25:06 UTC, FeepingCreature 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)


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


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


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.
Jul 04 2023
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Tuesday, 4 July 2023 at 13:25:06 UTC, FeepingCreature wrote:

 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.


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.


 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?


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.
Jul 05 2023
prev sibling next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 4 July 2023 at 11:08:02 UTC, Mike Parker wrote:






 * 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


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?
Jul 04 2023
prev sibling parent IGotD- <nise nise.com> writes:
On Tuesday, 4 July 2023 at 11:08:02 UTC, Mike Parker wrote:



 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.


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.
Jul 05 2023