SAVED_DELETED is not used in D11, D10, D9, or D8 and should be removed

This constant was introduced in Drupal 4.6.0 as a patch for the forum module in #19621: Sensible status messages for forum admin (five digit issue number!). There was no apparent discussion about the new constant.

In Drupal 5 and Drupal 6 and Drupal 7, this constant was only used by the taxonomy module. Forum no longer used it.

In D7 SAVED_DELETED was used only for the core taxonomy module, and only when deleting a taxonomy term or vocabulary in function taxonomy_term_delete($tid) or function taxonomy_vocabulary_delete($vid) - SAVED_DELETED was returned to indicate that fields attached to the deleted term/vocabulary had also been deleted.

There is literally no mention of SAVED_DELETED in the entire D8/D9/D10 codebase except for the "const" declaration.

SAVED_DELETED is one of three "SAVED" constants (SAVED_NEW, SAVED_UPDATED, and SAVED_DELETED) defined in common.inc. These are meant to be used as return codes for EntityInterface::save(), EntityStorageInterface::save(), EntityFormInterface::save(), etc.

But note that all these save() methods are explicitly documented to return just SAVED_NEW or SAVED_UPDATED - there is NO documentation that these will ever or can ever return SAVED_DELETED. Likewise there is no core method/function that actually returns SAVED_DELETED or documents SAVED_DELETED as a possible return value. It is just not used at all in D8/D9/D10.

I also searched the gitlab archives of all Drupal contributed modules at https://git.drupalcode.org/search?group_id=2&page=5&repository_ref=9.5.x... and the only uses I found were Drupal 7 modules - this does not appear in any D8, D9, or D10 contributions.

Regarding BC,

If this constant was being used in any core or contributed modules at all in D8/D9/D10, then I think it would be reasonable to ask about whether this should be done now or whether it has to be postponed to D11.

But this constant hasn't been used by contrib or core since D7. I don't see any need to delay removal at this point, as this is part of the core API and core NEVER returns this value and never documents that it can be returned.

For D10 we are taking steps to remove procedural code etc. in include files like common.inc, so I think removal of an unused constant SAVED_DELETED fits with the changes that are to be expected to occur in D10.

Not exactly. We have to deprecate it (by a CR) and to remove it in D11.

I don't understand why this was moved back to NW.

The draft CR deprecating the constant was created on 21 Dec 2022 by @danielveza, as requested.
He then moved the issue to NR.

So what needs to be done here to get this constant removed? It is not used by core or contrib in D11, D10, D9, or D8.

What does that mean? The CR exists, are you saying it just needs to be published? Then this issue should not be NW because it is ready for a maintainer to publish. If the CR is not sufficient then why? If the CR needs to be changed, what's wrong with it?

My question is still, what needs to be done?

#12 says deprecate by CR. That's why the status was NW.
There is no mention of deprecating in code.
That's why I'm asking.

"@TR documentation on how to deprecate constants is here"
Yeah but that was only created in May 2024.
Back in May 2022 when this issue was opened there was NO mechanism for deprecating constants.

What I'm hearing is that there is no good reason why this was put into NW two years ago, but now the solution has to be different because core changed. It shouldn't be this hard to get little things fixed.

so that we don't break contrib modules relying on them, like the ones that Ghost of Drupal Past found in #9, and this can happen in any minor release now, no need to grep contrib etc.

@ghost was citing the russian site, which was never up-to-date. But I did my search on gitlib, which *is* up-to-date, and I did that search both before I opened the issue and also gave the link in #6. No active, published contrib was/is using this constant.

Yes, deprecating is a much better way, but that method didn't exist two years ago so I pro-actively searched contrib and presented my results out of an abundance of caution.

I've now spent five minutes writing this up which I could have spent committing this issue if #25 hadn't been inaccurate.

And if the desired fix back then was to change the CR "introduced in" version from 10.1 to 11.0, then that could have been done in 10 seconds two years ago, rather than throwing it into "needs work" with an inaccurate reason why. And then NO-ONE would have had to spend 5 or 10 or 30 minutes more dealing with this.