Version 1.6 of ais/ai-00368.txt

Unformatted version of ais/ai-00368.txt version 1.6
Other versions for file ais/ai-00368.txt

!standard 13.12 (7)          04-11-09 AI95-00368/04
!standard J(1)
!class amendment 03-12-11
!status Amendment 200Y 04-06-29
!status WG9 approved 04-11-18
!status ARG Approved 9-0-0 04-06-13
!status work item 03-12-11
!status received 03-12-11
!priority Low
!difficulty Easy
!subject Restrictions for obsolescent features
!summary
The following restrictions identifier exists:
No_Obsolescent_Features
!problem
Some features are declared as obsolescent rather than removed from the language for backward compatibility reasons. It would be useful to make sure that new programs do not use these features by mistake.
!proposal
We introduce an additional restriction identifier that forbids the use of features defined in annex J.
The following restriction identifier is added:
No_Obsolescent_Features
!discussion
After much discussion it was agreed that this restriction was useful. It could be used to ensure that new programs do not inadvertantly use obsolescent features. But those who want to use ASCII, etc do not have to use the restriction.
However, there was some concern with the renamings in J.1 so their detection by the restriction is made implementation defined.
!wording
Add the following after 13.12(7):
The following restriction_identifier is language defined:
No_Obsolescent_Features
There is no use of language features defined in Annex J. It is implementation defined whether uses of the renamings of J.1 are detected by this restriction. This restriction applies only to the current compilation or environment, not the entire partition.
AARM Note: Reason: A user could compile a rename like "with Ada.Text_IO; package Text_IO renames Ada.Text_IO;". Such a rename must not be disallowed by this restriction, nor should the compilation of such a rename be restricted by an implementation. Many implementations implement these renames by compiling them normally; we do not want to require implementations to use a special mechanism to implement these renames.
Add the following to the introductory paragraph for Annex J:
Use of these features can be prevented by using pragma Restrictions(No_Obsolescent_Features), see 13.12.
!example
pragma Restrictions(No_Obsolescent_Features);
!corrigendum 13.12(7)
Insert after the paragraph:
The set of restrictions is implementation defined.
the new paragraphs:
The following restriction_identifier is language defined:
No_Obsolescent_Features
There is no use of language features defined in Annex J. It is implementation defined whether uses of the renamings of J.1 are detected by this restriction. This restriction applies only to the current compilation or environment, not the entire partition.
!corrigendum J(1)
Replace the paragraph:
This Annex contains descriptions of features of the language whose functionality is largely redundant with other features defined by this International Standard. Use of these features is not recommended in newly written programs.
by:
This Annex contains descriptions of features of the language whose functionality is largely redundant with other features defined by this International Standard. Use of these features is not recommended in newly written programs. Use of these features can be prevented by using pragma Restrictions(No_Obsolescent_Features), see 13.12.
!ACATS test
B-Test(s) should be constructed to verify that this restriction is enforced.
!appendix

From: Robert Dewar
Sent: Thursday, December 11, 2003  9:36 PM

Jean-Pierre Rosen wrote:

> !subject Restrictions for obscolescent features

The spelling is Obsolescent!

I object to this feature. In practice I think Annex J is
irrelevant. The recommendation not to use these features
is silly, and I see no reason to further enforce this
unwise decision.

For example, use Ascii is far more convenient than messing
with the Latin1 package, and I see no reason to say

Ada.Unchecked_Conversion

At most it is reasonable to have warnings for this case.

Another argument. Restrictions are not about enforcing
coding styles, but rather about restricting the language
for safety or efficiency purposes. Neither applies here.

****************************************************************

From: Jean-Pierre Rosen
Sent: Friday, December 12, 2003  9:08 AM

> > !subject Restrictions for obscolescent features
>
> The spelling is Obsolescent!

No objection :-)

This AI comes from the ARG meeting yesterday.
Now that we have (presumably) tagged incomplete types, it makes little
sense to allow taking 'Access of an (untagged) incomplete type, and then
check that the full type is tagged. It would be more regular to allow
'Access only if the type is declared tagged. However, requiring this
would create a (very unlikely, but possible) incompatibility. Therefore,
the group prefered to move this possibility to J, and create an AI to
make sure that this (and other) obsolescent feature is not used.

Now, I recognize that we did this without checking the whole content of
J, and the case of non "Ada." package names is a good one. So, let's do
it now and see what's in J:

J.1 Package renamings.
   Can (should) be kept.
J.2 Allowed Replacements of Characters
   I would be very happy to forbid this
J.3 Reduced Accuracy Subtypes
   Most people who would use this would expect them to behave
differently (those who know how they work don't use them), so I think it
would be nice to be able to protect the innocent here.
J.4 The Constrained Attribute
   Once again, few people know how to use this properly, and misuse is
likely
J.5 ASCII
   OK, this one can be convenient, although I'm not too strong about it.
J.6 Numeric_Error
   Definitely a good thing if it can be banned.
J.7 At Clauses
   Harmless, but there is no reason to use this syntax now.
J.7.1 Interrupt Entries
   This one is something useful (AFAIR, both Robert and I fought against
putting it in J). But OTOH, do current compilers support it? (Maybe yes
for compatibility reasons).
J.8 Mod Clauses
   Same as J.7
J.9 The Storage_Size Attribute
   Same as J.7

In short, J.1, J.5 (the ones mentionned by Robert) and J.7.1 have value.
In the case of J.7.1, the answer is easy: if you use this, don't put the
pragma restriction!
I would not say that of the other ones, since this pragma is intended to
protect casual users, and these casual users may use the short package
names. Personnaly, I could live without ASCII, and I tend more and more
to write Ada.Text_IO, but others may have stronger feelings.

So, should we make an exception for J.1 and J.5?

****************************************************************

From: Robert A. Duff
Sent: Friday, December 12, 2003  10:00 AM

Robert Dewar used to rant against Annex J during the Ada 9X project.
I now think he was right.  (Too late!)  One reason is that it causes all
manner of controversy -- people are offended when their favorite feature
gets banished to Annex J.

I have no objection to putting the weird 'Access thing in Annex J.

However, I fear that adding the new Restriction will cause the ARG to
argue all over again about what does and does not belong in Annex J,
and what should be controlled by the pragma.  We might even end up with
a No_Obsolescent_Features restriction that allows *some* obsolescent
features!  Then somebody will suggest calling it
No_EVIL_Obsolescent_Features, and then somebody will suggest having
*two* restrictions to make both sides happy, and on and on.

I say: the ARG has better things to do than argue about Annex J.

If users want warnings about Annex J features, let them ask their
compiler vendors.

****************************************************************

From: Robert I. Eachus
Sent: Friday, December 12, 2003  10:03 AM

I would rather take them out of Annex J entirely.  J.1 certainly
shouldn't be banned by the restriction, how would the compile "know"
that the reference to Text_IO was using a renaming of Ada.Text_IO put
there for compatibility reasons or as a project requirement?  Since
package renamings are used for other (non-obsolescent) reasons, it is
hard to draw the line there.

Similarly for package ASCII.  I often use it if I need the name of one
character, such as ASCII.LF.  I'd much rather say this time around that
the old ASCII has now been obsolescent for a decade, so we can make it
identical to Ada.Characters.Latin1.  (Which is currently the ASCII
standard, right?)

****************************************************************

From: Arnaud Charlet
Sent: Friday, December 12, 2003  10:11 AM

> If users want warnings about Annex J features, let them ask their
> compiler vendors.

Fully agreed. (and in the case of GNAT, the warning is already there: -gnatwj)

****************************************************************

From: Robert Dewar
Sent: Friday, December 12, 2003  10:42 AM

> If users want warnings about Annex J features, let them ask their
> compiler vendors.

I would not even mind implementation advice that suggests a mode in
which warnings are generated for use of Annex J features (that's what
we have in GNAT now).

****************************************************************

From: Tucker Taft
Sent: Sunday, December 14, 2003  6:18 PM

For what its worth, I think Annex J was an excellent idea.

New users completely ignore it, and so it adds no baggage
to understanding the language, but legacy users can continue
to use the features.  I see no harm in having the restriction
proposed, and of course noone has to use the restriction.

It is interesting that GNAT has a warning for Annex J usage, and also has
a "warnings are errors" flag, so you can effectively accomplish
the goal already with GNAT.  It doesn't seem bad to make this
a portable capability.  Also, I can see a project wanting to
make sure that new users don't have to read Annex J to understand
the project's source code.

Of course there are a few diehards (;-) who think there are some
gems of functionality in Annex J.  But I would claim that
given the criteria used for additions to the language, none
of them would make the cut at this point.  The language
is fully functional without them, and no new users seem to be clamoring
for us to remove any of them from the obsolescent "attic."

The renames are interesting, since of course any project could
define their own.  But I can see why a given project would
want to disallow use of the renamings, since they are not
available uniformly.  They are only provided for packages inherited
from Ada 83.  I would guess that new users of Ada probably
don't use the renames very frequently, in part because they
are not uniformly available, and it is too much bother to
remember which ones have them and which ones don't.

Personally, I use them in quick-and-dirty programs, but always
use the "Ada." prefix in "production" code, so I could easily
see imposing the restriction on one of our projects, simply
to provide better uniformity.  Pointless variation in language
usage is often discouraged in large projects.

****************************************************************

From: Robert Dewar
Sent: Monday, December 15, 2003  12:39 PM

Tucker Taft wrote:

> New users completely ignore it, and so it adds no baggage
> to understanding the language

Well many people are learning Ada to work with legacy code,
so they need to understand things like "with Text_IO" and
"ASCII.NUL".

> but legacy users can continue
> to use the features.  I see no harm in having the restriction
> proposed, and of course noone has to use the restriction.

No one argues that it is harmful, but lack of harm is not a
sufficient justification for a new feature.

> Of course there are a few diehards (;-) who think there are some
> gems of functionality in Annex J.  But I would claim that
> given the criteria used for additions to the language, none
> of them would make the cut at this point.  The language
> is fully functional without them, and no new users seem to be clamoring
> for us to remove any of them from the obsolescent "attic."

That's not surprising. Most "new users" will happily use ASCII.Nul
without knowing anything about Annex J, and those of us who do know
about Annex J know that the features there are a) normative and
b) not about to be removed from the language, so it really does
not matter if they are in J or not.

> The renames are interesting, since of course any project could
> define their own.  But I can see why a given project would
> want to disallow use of the renamings, since they are not
> available uniformly.

Do you know of any such projects, I don't.

> They are only provided for packages inherited
> from Ada 83.  I would guess that new users of Ada probably
> don't use the renames very frequently

Well I can't guess about new users I don't know about, but
those new users I do know about frequently use the renamings.

****************************************************************

From: John Barnes
Sent: Tuesday, December 16, 2003  2:28 AM

> For what its worth, I think Annex J was an excellent idea.

So do I and having just got home after that seemingly interminable flight
from LA I was amazed at the objection to the suggested Restriction
especially since GNAT has it. It was also somewhat annoying to find this
huge stream of messages under this same stream which were about alignment
and so should have had a different name.

Merry Christmas

****************************************************************

From: Robert Dewar
Sent: Tuesday, December 16, 2003  4:39 AM

That's a misunderstanding, GNAT has no such restriction. To us (and to
the Ada 95 RM) restrictions are about improving safety of code, or
allowing more efficient run-times, not about enforcing style rules.

So what we have is a warning for any usage of obsolescent features.
I think that IA suggesting such a warning is more appropriate than
a restriction pragma.

Part of my thinking here is that I would find it annoying if lots
of people adopted silly coding guidelines outlawing the use of the
renamed packages like Unchecked_Conversion, and even more annoying
if they outlawed Ascii.

It is really silly to have to write a long with (and either a use
or repeat the long package name) just to mention Ascii.NUL in a
particular procedure. This does not contribute to readability or
anything else.

By the way the GNAT warning is one that is not enabled by turning
on "all" warnings. It has to be enabled specifically. We have not
seen much evidence of any customers using this warning, but one
customer did say it would be useful. However, this customer was
actually referring to pragma Obsolescent, a way for writers of
libraries to mark entries as obsolescent, to generate this
warning. Really it is the pragma that this warning is about, the
inclusion of Annex J facilities was an after-thought (not one
that in fact I am sure was correct, but this is a frill anyway
which I doubt anyone is actually using).

Whence did the suggestion come from in the ARG context? Did some
real large scale Ada user suggest that it would be useful or was
it a self generated suggestion. I always find this important. For
us such things get implemented/included if a large important
customer wants them :-)

I would definitely look at pragma Obsolescent in GNAT if the ARG
does decide that this pragma restrictions is a better form than
a style warning.

****************************************************************

From: Jean-Pierre Rosen
Sent: Tuesday, December 16, 2003  7:28 AM

We were discussing forbidding completed an untagged deferred type with
a tagged one (now that we have tagged deferred types). Of course, this
would cause incompatibilities in rare cases, so the suggestion was to move
the possibility to annex J. Since the possibility is really weird, it seemed
appropriate to be able to forbid it at the same time through a restriction.

Note that there are other restrictions in annex J (reduced accuracy subtypes,
Numeric_Error, character replacements) that would be worth forbidding.

****************************************************************

From: Robert Dewar
Sent: Tuesday, December 16, 2003  9:17 AM

How do we know that this is rare? I do not accept guesses here.
Before introducing ANY incompatibilities, no matter how "rare"
they may be guessed to be, we should do empirical investigation.
One incompatibility in legacy code cancels out the value of many
supposedly essential new bells and whistles, so this is really
important investigation.

An obvious step before even considering sanctioning any kind of
incompatibility is to ask compiler vendors to investigate their
existing customer base test suites and report back to the ARG.

****************************************************************

From: Tucker Taft
Sent: Tuesday, December 16, 2003  12:23 PM

In any case, we decided not to forbid it, but rather to consider providing
a Restriction identifier which would forbid it.

And yes, I agree that particularly vendor members of the ARG should
make an effort to quantify the impact of any upward incompatibility
using whatever data they have at their disposal, or can generate reasonably.

****************************************************************


Questions? Ask the ACAA Technical Agent