Version 1.1 of acs/ac-00182.txt

Unformatted version of acs/ac-00182.txt version 1.1
Other versions for file acs/ac-00182.txt

!standard 13.12          10-01-15 AC95-00182/01
!class Amendment 10-01-15
!status received no action 10-01-15
!status received 08-10-21
!subject Pragma Features
!summary
!appendix

From: Tucker Taft
Date: Tuesday, October 21, 2008  9:31 PM

[Editor's note: The quoted text comes from the discussion of AI05-0123-1.]

> I had imagined using a pragma Features for the various Ada 2005
> features which might be provided "piecemeal."
> I suppose it would be most important for features that involve any
> kind of potential semantic inconsistency, such as the
> return-by-reference vs. build-in-place, but it could be useful as
> documentation for the set of features expected to be fully supported.
> The danger is that some compiler might accept the syntax for something
> like access-to-subprogram, but not support the full downward closure
> semantics.
>
> Or more obviously, whether null values can be passed to access
> parameters might not be at all obvious, because we have encouraged Ada
> 95 compilers to accept, and ignore, the "not null" syntax on access
> parameters.  I can see the same thing effectively happening with, say
> "private with,"
> where the compiler would be augmented to accept the syntax, but treat
> it as equivalent to simply "with."  This is most tempting when trying
> to compile the container packages, where you might be able to get away
> with accepting the Ada 2005 syntax they use, but "punt" on the
> semantics where possible.
>
> I know I was tempted by that recently, because the latest GNAT sources
> use container packages, and I was trying to compile them with AdaMagic
> to host the gnat2scil on my laptop in the absence of a GNAT version
> for Mac OS X that could compile the inspector.

Another feature that comes to mind for this pragma is whether aliased records
can be unconstrained. Clearly if you are going to rely on that, you would like
to be sure that the compiler allows for that, so some kind of pragma asserting
use of that feature would be helpful.  E.g.

    pragma Features(Unconstrained_Aliased_Records);

You can't easily be sure whether the feature is supported in other ways, since
it doesn't involve any new syntax. You could use this pragma if you want to be
sure when you deliver source code to someone else to compile, that they won't be
stuck debugging something due to using the wrong compiler, or the right compiler
in the wrong mode.

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

From: Robert Dewar
Date: Tuesday, October 21, 2008  9:37 PM

> Another feature that comes to mind for this pragma

I wonder if "allocate max space for variant records"
is also in this category.

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

From: Randy Brukardt
Date: Wednesday, October 22, 2009  8:17 PM

I've always been in favor of this idea (it was AI95-00222 the last time around),
but it would be valuable to recall why it wasn't adopted the last time. Perhaps
there is a way to answer those objections??

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

From: Tucker Taft
Date: Wednesday, October 22, 2009  9:37 PM

I think there were some "political" objections, which are probably mostly
overcome by events, now that Ada 2005 is an ISO standard.

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

From: Randy Brukardt
Date: Friday, November 7, 2008  9:32 PM

> I've always been in favor of this idea (it was AI95-00222 the last
> time around), but it would be valuable to recall why it wasn't adopted
> the last time. Perhaps there is a way to answer those objections??

I happened across the following when I was working on the schedule
yesterday:

  AI-222/01 Pragma Feature

  Tucker says that he still thinks this is a good idea. He seems to be alone in
  strongly supporting this idea.

  No Action: 10-0-0.

Which doesn't provide much information about why this was rejected. One reason I
recall was there wasn't compelling enough examples of its use, so Tucker needs
to work on those. :-)

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

From: Tucker Taft
Date: Friday, November 7, 2008  10:31 PM

I think when we were working on Ada 2005, it was not politically feasible to imply that compilers might provide partial support, or that users might begin to pick and choose among features.  But I think we are beginning to see this happening, and as we see
m to have decided to continue the amendment process beyond 2005, in what I foresee becoming somewhat of a rolling set of amendments, I think this pragma may find a natural role.  It is nice to think that there will be clear borders between Ada 83, Ada 95, 
Ada 2005, Ada 201x, etc, but in reality the borders are beginning to get fuzzy.
I suspect there are people who will jump from Ada 83 to Ada 2005, without ever stopping at the Ada 95 waystation, simply because if you have decided to finally start using OO features, why not get the full suite, including interfaces and object.operation s
yntax, and get synchronized and tagged features nicely integrated?

I don't think we want to accept that GNAT will be the only compiler supporting Ada 2005 features, but it may be the only one supporting nearly all of Ada 2005 for quite a while.  Until other compilers achieve full coverage of Ada 2005, it seems more import
ant for users to identify exactly what features they are depending on, especially for features where there is no new syntax, simply new semantics.

Hence, Unconstrained_Aliased_Records seems a good candidate for this pragma.  I would be afraid to depend on this feature unless I had a way to indicate my dependence in a pragma that could *not* be ignored by an implementation, because otherwise I would j
ust be in for some nasty, yet subtle surprises.  Similarly, if we solve the private type in instances with a bit of freezing-point slight-of-hand, you would want to indicate a dependence on such a feature somehow, rather than just getting bizarre errors on
 porting to a new compiler.

I suppose since I apparently voted no action last time (clever of me!), I can legitimately ask to reopen the vote (I think that's how "Robert's Rules" work).  So perhaps I am at least asking to get it back on to the agenda for a future ARG meeting.

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

From: Randy Brukardt
Date: Saturday, November 8, 2008  12:35 AM

Fair enough for me. I'll vote with you on this one so that I don't have to argue
with Ed whether it should be on the list.

However, I just went back and looked at AI95-0222-01, and it does not propose
any specific features or names thereof. I think that was a real concern with it
- there were no concrete examples of what a feature is or how it would be used.
You've mentioned such examples in this thread, and what we need is a rewrite of
AI95-0222-1 that includes those examples (probably with real wording for them --
make it as concrete as possible).

You've mentioned Unconstrained_Aliased_Records, and the thread was started for
Untagged_Record_Equality_Composes. (I could see doing that latter under an Ada
2005 switch, but not for an Ada 83 or Ada 95 switch.) There might be others that
come to mind with some thinking. One possibility would be Null_Access_Parameters
(since in Ada 95, they are null-excluding, and if you want to pass null to them,
you'll get bizarre Constraint_Errors and no compile-time warning). A more
general possibility would be Limited_Initialization (but there you'd usually get
compile-time errors of some sort, not necessarily very enlightening).

As Robert said, we'd need several examples in order to make the general feature
worthwhile. There probably are enough with some effort. I'm counting on you to
make the needed rewrite of AI95-0222-1.

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

From: Tucker Taft
Date: Saturday, November 8, 2008   7:45 AM

OK, I accept the assignment.  Another one which comes to mind is
Limited_Build_In_Place_Function_Return, since the errors you get if you are
presuming the wrong thing (return-by-ref vs. build-in-place) about limited
function return could be pretty mysterious.

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


Questions? Ask the ACAA Technical Agent