Plan for phasing out obsolete identifiers

[fingolfin]

Right now we mark some stuff as obsolete, and even have a warning class InfoObsolete for it. But we are completely toothless about phasing out these identifiers, and indeed, recently some of them got used again in the library (see parts of PR #1452).

Part of the problem is that InfoObsolete default to 0, so most people never will now they are using obsoletes. To a degree, this default level makes sense because it avoids warnings about packages that still use these obsoletes.

I propose the following changes:

Revise default InfoObsolete level and how we use it.

I propose we change the the default level of InfoObsolete to 1. Then we revise all uses of InfoObsolete:

• For things were we determine that packages do not use them anymore, warn about them at level 1 (so the user will get warning about them by default
• for things which are still used in packages, use level 2 or higher
• To achieve this, we can add an extra level argument to DeclareObsoleteSynonym.
• in order to not flood the user with warnings for cases were an obsolete function is used in a loop, we could also enhance DeclareObsoleteSynonym in such a way that the info message is only shown once (or only shown every few seconds/minutes).

Add warnings for access to obsolete global variables

We don't really warn about global variables being used (only about global functions, operations, attributes etc.). We could achieve this with a trick, though, by abusing the "automatic variables" feature (even though some people might want to phase it out eventually for HPC-GAP... but in HPC-GAP, we can use TLS variables for the same effect).

The idea is that an automatic variable is only actually initialized when it is actually accessed, and this is done by invoking a special function returning the value for the variable -- and that function can of course issue an Info warning. This warning will only be shown once, of course -- that might actually be an advantage. Indeed, come to think about it, the same "automatic variable" trick could/should perhaps be used for obsolete functions, operations etc., too, to get the message only once.

Distinguish different "stages" of obsolete identifiers

We could refine DeclareObsoleteSynonym to distinguish two kinds of obsoletes: "obsolete alias, on by default" (as is currently the case), and also "obsolete alias, off by default").
Then we could refine the -O option which turns off obsoletes, to switch between three (instead of two) modes: "all obsoletes on"; "all obsoletes of"; and "some obsoletes on". We might eventually make the last one the new default.

The two kind of obsoletes could actually simply depend on their info level: Things with level 2 are not currently being warned about, and thus should not be turned off; level 1 would be warned about, so we turn it off... or perhaps use more levels: by default, level 0 obsoletes get turned off, level 1 get warned about, level 2 are silently accepted; then the -O option (or its successor) adjust which levels get warnings, which errors.

[olexandr-konovalov]

And we could document DeclareObsoleteSynonym as well (cf. PR #1452)

[fingolfin]

I am not sure I would want that. It's an internal feature of the library

[olexandr-konovalov]

Unless package authors would like to use it, too.

[fingolfin]

Removing the milestone. Nobody is working on this right now; it only makes sense to set a milestone if we have a clear plan how to solve a given issue, resp. volunteers who promise to take care of it in a given time frame.