!standard  13.4(4)                              12-01-06    AC95-00220/00
!class Amendment 11-04-01
!status received no action 11-04-01
!status received 11-04-01
!subject Function bodies for enumeration literals
!summary

!appendix

From: Steve Baird
Sent: Friday, April 1, 2011  12:47 PM

Regarding the recent discussion of using aspect notation to allow user-specified
function bodies for enumeration literals, as in

   package Pkg is
     type Enum is (Aaa, Bbb, Ccc);

     type Derived_Enum is new Enum with
        Enumeration_Implementation =>
           (Aaa | Ccc => <>, Bbb => Bbb_Implementation);

     function Bbb_Implementation return Derived_Enum;
   end Pkg;

I agree with the points that have been made about staticness and formal derived
types, and about forbidding a conflicting enumeration_representation_clause.

The proposed semantics for for-loops seem consistent, but I am still unclear
about what it means when such a type is used to index an array. I think we want
to follow the model of AI05-153 and prohibit using these enumeration types as
index subtypes.

Without this restriction, I think this feature would introduce unnecessary
complexity.

P.S. If, as the original proposal suggested, it is specifically intended that
these types are to be used to index entry families, then I think we at least
need to explicitly specify what it means for the implementation function to be
"well behaved".

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

From: Randy Brukardt
Sent: Friday, April 1, 2011  1:18 PM

I don't recall any such discussion. Was this an AdaCore-only discussion?
Would anyone care to explain why this would be a good idea?

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

From: Steve Baird
Sent: Friday, April 1, 2011  1:28 PM

> Remember that the homework deadline is this Friday (April 1).

> I don't recall any such discussion. Was this an AdaCore-only discussion?
> Would anyone care to explain why this would be a good idea?

See AI05-040111 ,

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

From: Gary Dismukes
Sent: Friday, April 1, 2011  1:32 PM

...
> Without this restriction, I think this feature would introduce
> unnecessary complexity.

That all sounds eminently reasonable.

While this would undoubtedly be a useful feature (though I probably wouldn't use
it myself), I'm wondering about the semantics of 'Image for such a type.  Should
the image of the literal corresponding to the body be "Bbb",
"Bbb_Implementation", or simply the normal Image function applied to the result
of calling the function?

Also, if we're going to add such a feature, I think we may as well go the extra
mile and make it really useful by making it possible to shrink and extend the
type (even simultaneously).  For example:

   type Derived_Enum is new Enum with
      Enumeration_Implementation =>
          (Aaa => null, Bbb | Ccc => <>, others => (Ddd, Eee));

Of course we can argue about the details of the right syntax, etc., but none of
this seems particularly difficult from an implementation point of view.

> P.S. If, as the original proposal suggested, it is specifically
> intended that these types are to be used to index entry families, then
> I think we at least need to explicitly specify what it means for the
> implementation function to be "well behaved".

No comment.

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

From: Robert Dewar
Sent: Friday, April 1, 2011  2:22 PM

> Without this restriction, I think this feature would introduce
> unnecessary complexity.

IMO, this feature DOES introduce unnecessary complexity, period!

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

From: Tucker Taft
Sent: Friday, April 1, 2011  3:17 PM

April Fools!

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