!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! ***************************************************************