!standard 03.05.04 (09) 00-12-02 AC95-00002/01 !standard 03.05.07 (11) !standard 03.05.09 (14) !standard 03.05.09 (16) !status received 00-12-02 !subject The conversions implicit in numeric type conversions do not cause freezing !summary The conversions mentioned in 3.5.4(9) (for signed integer type definitions), 3.5.7(11) (for floating point definitions), 3.5.9(14) (for ordinary fixed point definitions), and 3.5.9(16) (for decimal fixed point definitions) are not implicit subtype conversions in the sense of 4.6(59-60), as they do not occur during overload resolution. Therefore, they do not trigger 13.14(8.2/1), and the types are not frozen by these conversions. The index of the standard is incorrect when it calls these "implicit subtype conversions". !appendix From: Ivan B. Cvar Sent: Thursday, November 30, 2000 11:46 AM !topic Real_Range_Specification Freezes the Real Type Itself !reference RM95-13.14(10) !from Ivan B. Cvar 00-11-30 !keywords real_range_specification freezing conversion AI95-00106 !discussion RM95 3.5.7(8) and 3.5.9(16) say that the bounds of a real_range_specification are implicitly converted to the type being defined. But RM95 13.14(8,10) say that a static expression freezes both its type and its subtype. I'd guess RM95 13.14(10) should make another exception for this case, but it doesn't. This means that a type's real_range_specification freezes the type itself! This seems very wrong. package Example is Pi : constant := 3.141_592_653_589_793; Radians_In_Circle : constant := 2.0 * Pi; type Angle is digits 15 range -Radians_In_Circle .. Radians_In_Circle; type REG_FIX is delta 0.001 range -Radians_In_Circle .. Radians_In_Circle; for Angle'size use 64; -- LEGAL or NO? -- see RM95 13.1(9) for REG_FIX'size use 64; -- LEGAL or NO? -- see RM95 13.1(9) end; BTW, the Technical Corrigendum 1 doesn't fix this problem which is somewhat related to AI95-00106. **************************************************************** From: Robert Dewar Sent: Thursday, November 30, 2000 12:04 PM this example is most certainly legal. If the RM says otherwise, it is simply wrong (I am talking about the package Example previously given). **************************************************************** From: Randy Brukardt Sent: Thursday, November 30, 2000 12:15 PM I think everyone agrees with this. The question is whether the RM (as corrected by TC1) is wrong. **************************************************************** From: Gary Dismukes Sent: Thursday, November 30, 2000 12:17 PM > RM95 3.5.7(8) and 3.5.9(16) say that the bounds of a > real_range_specification are implicitly converted to the type being > defined. But RM95 13.14(8,10) say that a static expression freezes both > its type and its subtype. I'd guess RM95 13.14(10) should make another > exception for this case, but it doesn't. > > This means that a type's real_range_specification freezes the type itself! > This seems very wrong. That's not right. While the range expressions are implicitly converted to the type, the expressions themselves are of some other type (in your example they're of type universal_real), so they freeze that type, not the new type being defined. **************************************************************** From: Randy Brukardt Sent: Thursday, November 30, 2000 1:22 PM > RM95 3.5.7(8) and 3.5.9(16) say that the bounds of a > real_range_specification are implicitly converted to the type being > defined. You mean 3.5.7(11). It says in part: If a real_range_specification is given, then the subtype is constrained to a range whose bounds are given by a conversion of the values of the simple_expressions of the real_range_specification to the type being defined. The AARM indexes this under "implicit subtype conversion". 3.5.9(16) is similar. > But RM95 13.14(8,10) say that a static expression freezes both > its type and its subtype. 13.14(8/1) says (in part, this part is not changed by the Corrigendum): A static expression causes freezing where it occurs. That clearly applies here (real_range_specification's bounds are defined to be static_simple_expressions, see 3.5.7(3)). 13.14(10) says: At the place where an expression causes freezing, the type of the expression is frozen, unless the expression is an enumeration literal used as a discrete_choice of the array_aggregate of an enumeration_representation_clause. Thus the type is frozen. Oops! Note that the corrigendum adds 13.14(8.2/1): If an expression is implicitly converted to a type or subtype T, then at the place where the expression causes freezing, T is frozen. but that isn't really the problem here. (It is intended to handle expressions which contain implicit conversions which are not the ultimate type of the expressions). > This means that a type's real_range_specification freezes the > type itself! This seems very wrong. Yes, that seems to be clearly the case. Note that signed_integer_type_definitions have the same problem; see RM 3.5.4(3) & 3.5.4(9). Thus we conclude that all representation items are illegal on all user-defined signed integer, float, and fixed point types. :-) I think we can all agree that this is a bogus result. I'll write up an AI for it. However, I'm not sure what an appropriate fix is. Should we simply add signed_integer_type_definition and real_range_specification to the "unless" part of 13.14(10)? **************************************************************** From: Tucker Taft Sent: Thursday, November 30, 2000 2:17 PM Randy Brukardt wrote: > ... > > Thus we conclude that all representation items are illegal on all > user-defined signed integer, float, and fixed point types. :-) I think we > can all agree that this is a bogus result. I'll write up an AI for it. Don't bother. There is no problem. The type of the static expressions is not the same as the newly created type. [For more details, see the other responses from me and Gary.] **************************************************************** From: Tucker Taft Sent: Thursday, November 30, 2000 12:27 PM The conversion happens after overload resolution in this case. The static expression is *not* of the new type (it can't be, since the type doesn't exist yet). The value is converted to the new type, that is true, but that does not change the fact that the actual "static expression" is not of this new type. The freezing rules have to do with the characteristics of constructs that appear in the source, not on the semantic actions that take place as a result of the constructs. **************************************************************** From: Robert Dewar Sent: Thursday, November 30, 2000 1:38 PM I agree with this analysis (though one must say that it should be entered in the "angels-dancing-on-a-pin" contest :-) **************************************************************** From: Randy Brukardt Sent: Thursday, November 30, 2000 6:46 PM Humm, doesn't the implicit conversion trigger the AI-106 (and TC) rule in this case? To wit (13.14(8.2/1)): If an expression is implicitly converted to a type or subtype T, then at the place where the expression causes freezing, T is frozen. If so, then we still have the problem. It certainly seems like it ought to; the expression may not have the new type, but the implicit conversion sure does. And this rule was written specifically to catch similar cases in expressions (but certainly not in types). Robert said: >I agree with this analysis (though one must say that it should be entered >in the "angels-dancing-on-a-pin" contest :-) Certainly it sounds that way to me. Except that AI-0106 seems to have taken away the pin without paying any attention to what happened to the angels... **************************************************************** From: Gary Dismukes Sent: Thursday, November 30, 2000 6:06 PM Tuck wrote: > > The conversion happens after overload resolution in this case. > The static expression is *not* of the new type (it can't be, since > the type doesn't exist yet). The value is converted to the new type, that > is true, but that does not change the fact that the actual "static expression" > is not of this new type. The freezing rules have to do with the > characteristics of constructs that appear in the source, not on the > semantic actions that take place as a result of the constructs. However it seems that the TC has now introduced various cases of freezing due to implicit actions (specifically implicit calls and implicit conversions, as documented in AI-106). In particular, as Randy wrote: > Note that the corrigendum adds 13.14(8.2/1): > > If an expression is implicitly converted to a type or subtype T, then at > the place where the expression causes freezing, T is frozen. > > but that isn't really the problem here. (It is intended to handle > expressions which contain implicit conversions which are not the ultimate > type of the expressions). Well, maybe that is a problem, if the conversions in floating-point type declarations are properly categorized as implicit conversions. This rule ostensibly applies to all implicit conversions, so how can we argue that it doesn't affect these conversions? As far as I can see, 13.14(8.2/1) is broken. The principle that static semantic rules (not to mention dynamic semantic rules ;-) do not affect legality makes perfect sense, but then what do we make of this TC-revised freezing rule that mentions implicit conversions? It looks to me like this rule should not be referring to implicit conversions, which happen as part of other semantics, but somehow needs to refer to resolution rules (expected type stuff). **************************************************************** From: Robert Dewar Sent: Thursday, November 30, 2000 7:22 PM Why don't we give this the priority it deserves, which is very low, and put it on the stack to worry about when there is nothing important to worry about. I know, it is *so* tempting to indulge in entertaining wording discussions :-) **************************************************************** From: Tucker Taft Sent: Thursday, November 30, 2000 10:32 PM Randy Brukardt wrote: > > > The conversion happens after overload resolution in this case. > > The static expression is *not* of the new type (it can't be, since > > the type doesn't exist yet). The value is converted to the new type, that > > is true, but that does not change the fact that the actual "static > > expression" is not of this new type. The freezing rules have to do > > with the characteristics of constructs that appear in the source, not > > on the semantic actions that take place as a result of the constructs. > > Humm, doesn't the implicit conversion trigger the AI-106 (and TC) rule in > this case? There is no "implicit conversion" in the sense this refers to. The values are converted as part of the *semantics* of the construct. Implicit conversion is something performed during overload resolution to make an expression match its expected type. > ... To wit (13.14(8.2/1)): > > If an expression is implicitly converted to a type or subtype T, then at > the place where the expression causes freezing, T is frozen. > > If so, then we still have the problem. It certainly seems like it ought to; > the expression may not have the new type, but the implicit conversion sure > does. Again, this is only if overload resolution is performing the implicit conversion. Here, the conversion is part of the semantics, not the overload resolution. If anything, the expected type is "any real type" which is closest to "universal_real" and the implicit conversion performed at overload resolution time (which is the one that matters for freezgin) occurring would be to universal_real, not to the newly defined type. > ... And this rule was written specifically to catch similar cases in > expressions (but certainly not in types). > > Robert said: > >I agree with this analysis (though one must say that it should be entered > >in the "angels-dancing-on-a-pin" contest :-) > > Certainly it sounds that way to me. Except that AI-0106 seems to have taken > away the pin without paying any attention to what happened to the angels... I don't agree. AI-106 doesn't apply. There is no "implicit" conversion here, which is a term that relates to something happening during overload resolution. **************************************************************** From: Randy Brukardt Sent: Thursday, November 30, 2000 10:39 PM Sounds like even *more* dancing on a pin. Anyway, if this is correct, then the index of the ARM and AARM is wrong, which includes paragraphs 3.5.4(9), 3.5.7(11), and 3.5.9(14, 16) under "implicit subtype conversion". Luckily the index isn't normative. The index points to a note in 4.6 (4.6(59-60)) as the definition of "implicit subtype conversion". This note matches Tucker's description, but of course that isn't normative either. Looks like we have at least a presentation issue (if we agree with Tucker's dancing here, then those index entries should be removed). Of course, presentation issues are easy to resolve. **************************************************************** From: Robert Dewar Sent: Thursday, November 30, 2000 10:39 PM What a horrible nightmare of terminological chaos explicit conversions implicit conversions and now, post-overload resolution conversions that are neither explicit nor implicit UGGGH! ****************************************************************