The Art of Deprecation

At a recent SystemVerilog requirements gathering meeting,I was quite amused to see “deprecating features” come out as one of the top 10 user requested priorities for the next revision of the IEEE 1800 standard. Even more amazing was that this request came out without listing which features were to be considered for deprecation.

P1800 Requirements gathering meeting 2/27/2010

I’m sure most people don’t understand the meaning of the word deprecate. I thought I understood until I looked it up in a dictionary. According to Merriam-Webster:

Deprecate:

1 a archaic : to pray against (as an evil) b : to seek to avert <deprecate the wrath…of the Roman people — Tobias Smollett>
2 : to express disapproval of
3 a : play down : make little of <speaks five languages…but deprecatesthis facility — Time> b : belittle, disparage<the most reluctantly admired and least easily deprecated of…novelists — New Yorker>

In computer science standards and documentation, deprecation has come to mean to supersede or discourage use of a feature. It does not mean a feature has to be removed to be compliant with the standard. You can’t remove a feature from an existing standard; you can only remove a feature from being documented in a future standard. No vendor is going to immediately remove a feature from a tool that it has already implemented and in widespread use without ample warning and without providing a practical alternative to the user. Typically, a deprecated feature is never removed from support in a tool unless in the rare case it’s needed to allow for a future enhancement.

The current standard lists in Annex C.4 the defparam and the procedural continuous assignment statements as candidates for deprecation. Listing candidates for deprecation seems to be almost the same as actually deprecating them without removing the LRM. No tool will remove support for these statements regardless of whether they are candidates or actually removed from the LRM.

Q: So why go though the trouble of deprecating a feature in a standard?
A: Well, to discourage use of that feature.

Q: And why is that a good thing to do?
A: It makes learning the language and maintaining existing code much easier.

Take an example from the current Verilog and SystemVerilog LRMs. The logic data type was added to supersede the reg data types; they both have the same semantics. Anyone with a history of Verilog will understand the change in keywords, but someone new to SystemVerilog will be left wondering why there are two keywords for the same thing. And then there is the issue of trying to maintain the LRM so that all references to reg also include logic and the other way around. If someone misses that in one place, people will begin to think the two keywords have different behaviors.

It seems it’s always easier to add new features than to remove them. There are many places to create lists of your favorite enhancements. At the same time, people complain about the size of the Language Reference Manual – it’s over 1200 pages. Doug Smith of Doulos writes “Will this language ever stop exploding?”

So here is my list for deprecation, as well as a place for other to add their list by commenting here.

1. Program blocks
2. Reg data type – see above
3. Wildcard associative array index types
4. Un-typed mailboxes
5. Dynamic array copy A = new[]B redundant with A = B
6. always @(*) – superseded by always_comb

From http://go.mentor.com/the-art-of-deprecation

Tags: SystemVerilog

This entry was posted on Tuesday, March 23rd, 2010 at 11:52 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.