!standard 3.10 (06) 07-05-25 AI95-00447/03 !class binding interpretation 06-02-20 !status ARG Approved 12-0-1 06-06-09 !status work item 06-02-20 !status received 06-02-20 !priority High !difficulty Easy !subject Null_exclusions allowed in Ada 95 !summary Ada 95 allows "not null" in anonymous access types, so that programs can be written that have the same semantics in both Ada 95 and Ada 2005. !question Ada 2005 introduces the null exclusion ("not null"), and correspondingly changes anonymous access types so that they don't automatically exclude null. That means that: procedure P (A : access T); has subtly different semantics in Ada 95 and Ada 2005. In mixed environments (which are likely to be common during the transition to Ada 2005), this poses a problem, as there is no way to write a program so as to get the same semantics in each language. This magnifies the effect of an otherwise minor incompatibility. If "not null" was allowed in Ada 95 anonymous access types (optionally, of course), this problem would be substantially reduced. Should this be allowed? (YES! YES! YES!) !recommendation (See summary.) !wording Replace 3.10(6) by: access_definition ::= [not null] access subtype_mark !discussion The use of "not null" has no semantic effect in Ada 95. However, if the code using "not null" is compiled on an Ada 2005 implementation, the semantics will be unchanged, while the semantics will change if it is omitted. The main objection to this change is that not all Ada 95 compilers will implement this change, and thus the portability of Ada 95 code will be reduced. In order to mitigate this issue, we encourage the ACAA to issue an Ada 95 ACATS test checking for this capability. This should have the effect of increasing awareness of the change amongst Ada vendors, and should encourage them to implement this easy change as soon as possible. !ACATS test Create/modify an ACATS test to check that "not null" is allowed, and properly raises Constraint_Error if passed null. (Note that there isn't a test for 4.6(49), so it is unclear whether this property is tested at all in the ACATS.) !appendix From: Randy Brukardt Sent: Thursday, February 2, 2006 9:26 PM Here's another comment from Canada for which the resolution requires additional input to resolve. The comment from Canada: Problem: There is an imbalance in the proposed new syntax for Ada 2005 with regard to null exclusion. Specifically, the new syntax allows the programmer to explicitly specify whether an access type excludes the null value, but there currently are no means for a programmer to explicitly specify whether an access type includes null. To exclude null, the programmer can add the clause "not null" to an access type definition in Ada 2005. In order to allow the programmer to specify that an access type can be assigned null values, the clause "accept null" seems like it would fit naturally into the syntax to convey that meaning. Conceptually, an accept statement in Ada defines which operations can be performed on a particular task. Here we are defining an operation that can be performed on a particular access type. Therefore, the following could all be valid; type my_access_type is access foo; --- Defaults to either not null or accept null depending on context as per Ada 2005 type my_access_type is not null access foo; -- Cannot be assigned null values type my_access_type is accept null access foo; -- Can be assigned null values The first form would be considered a short hand for either the second or the third form depending on whether the usage was for a controlling access type or not. Having a means to explicitly specify whether or not a type can accept null values helps to reduce the inconsistency in the treatment of the first form for controlling vs non-controlling access types. There is no inconsistency when the second or third form is used. Having the third form means that there would always be a way to eliminate this inconsistency. This new proposed syntax means that the programmer will have a way to express exactly how the access type can be used with respect to null values. If the programmer specifies either "not null" or "accept null" then it is clear that the programmer has considered null usage, and further it allows the compiler to flag errors when the programmer is intending to use an access type in a manner that is not permitted. For example, if a programmer specifies "accept null" for a controlling access type, the compiler would generate an error at compile time. This also improves software maintainability and improves safety. For example if code is written where an access type can accept null, and later that code is modified so that the access type is made to be a controlling access type, the compiler can flag the need for changing the null exclusion whereever it is needed. If the first form is used, then there is an implicit change in how null values can be assigned which might introduce run time failures into the code. Note also that this feature can be added to the language without adding any new reserved words. The overriding and not overriding clause was added to Ada 2005 for very similar reasons, and apparently the reasons were considered strong enough to warrant adding a new reserved word to the language. Finally, note that it seems likely this feature would be relatively easy to implement for compiler vendors. Proposed revisions to AMENDMENT 1 (Draft 15) to support null_inclusion specification ------------------------------------------------------------------------- Section 3.10 Replace paragraph 2: [AI95-00231-01] access_type_definition ::= access_to_object_definition | access_to_subprogram_definition by: access_type_definition ::= [null_exclusion_indicator] access_to_object_definition | [null_exclusion_indicator] access_to_subprogram_definition Replace paragraph 6: [AI95-00231-01; AI95-00254-01; AI95-00404-01] access_definition ::= access subtype_mark by: null_exclusion_indicator ::= [null_inclusion | null_exclusion] null_inclusion ::= accept null null_exclusion ::= not null access_definition ::= [null_exclusion_indicator] access [constant] subtype_mark | [null_exclusion_indicator] access [protected] procedure parameter_profile | [null_exclusion_indicator] access [protected] function parameter_and_result_profile Replace paragraph 13: [AI95-00230-01; AI95-00231-01] For each (named) access type, there is a literal null which has a null access value designating no entity at all. The null value of a named access type is the default initial value of the type. Other values of an access type are obtained by evaluating an attribute_reference for the Access or Unchecked_Access attribute of an aliased view of an object or non-intrinsic subprogram, or, in the case of a named access-to-object type, an allocator, which returns an access value designating a newly created object (see 3.10.2). by: For each access type, there is a null access value designating no entity at all, which can be obtained by (implicitly) converting the literal null to the access type. The null value of an access type is the default initial value of the type. Non-null values of an access-to-object type are obtained by evaluating an allocator, which returns an access value designating a newly created object (see 3.10.2), or in the case of a general access-to-object type, evaluating an attribute_reference for the Access or Unchecked_Access attribute of an aliased view of an object. Non-null values of an access-to-subprogram type are obtained by evaluating an attribute_reference for the Access attribute of a non-intrinsic subprogram. A null_inclusion in a construct specifies that the null value does belong to the access subtype defined by the construct, that is, the access subtype includes null. A null_exclusion in a construct specifies that the null value does not belong to the access subtype defined by the construct, that is, the access subtype excludes null. In addition, the anonymous access subtype defined by the access_definition for a controlling access parameter (see 3.9.2) excludes null. Finally, for a subtype_indication without a null_exclusion_indicator, the subtype denoted by the subtype_indication excludes null if and only if the subtype denoted by the subtype_mark in the subtype_indication excludes null, otherwise the subtype denoted by the subtype_mark in the subtype_indication includes null. Replace paragraph 22: [AI95-00433-01] type Peripheral_Ref is access Peripheral; -- see 3.8.1 type Binop_Ptr is access all Binary_Operation'Class; -- general access-to-class-wide, see 3.9.1 by: type Peripheral_Ref is not null access Peripheral; -- see 3.8.1 type Binop_Ptr is accept null access all Binary_Operation'Class; -- general access-to-class-wide, see 3.9.1 Section 3.10.1 Replace paragraph 7: [AI95-00326-01; AI95-00412-01]  as the subtype_mark defining the subtype of a parameter or result of an access_to_subprogram_definition; by:  as the subtype_mark in the subtype_indication of a subtype_declaration; the subtype_indication shall not have a null_exclusion_indicator or a constraint; [End of comment from Canada] --- This comment seems to come out of left field: the syntax for null exclusions hasn't significantly changed since the concept was defined more than five years ago. Moreover, WG 9 approved this syntax and semantics over 18 months ago. Where was this comment when it would have been practical to change the language? The proposal *seems* simple enough, but it would be a very large change at this point. It would be necessary to check all of the wording in the standard for possible rewording. I'm dubious that the above are the only changes needed. For instance, 6.1(13/2) and 6.1(15/2) use "null_exclusion"; it would seem necessary to change them and the associated wording as above. That's true in other parts of the standard, as well. Moreover, this would be "optional" syntax. That is, syntax which is not required and duplicates the semantics of some other syntax (in this case, the absence of syntax). We've had a very strong desire to avoid adding such syntax in Ada 2005. Indeed, we removed the consistent "access all T" from anonymous access types (over my object, BTW) to avoid this sort of syntax. The intent of the current standard is that the *lack* of a null exclusion indicates the ability to use null. That's true everywhere except for controlling access parameters - for which using null is *never* allowed. Since there are only two states, that certainly is sufficient to describe them appropriately. The concern about maintenance is certainly a real one. However, *adding* a null exclusion to an existing subtype is almost never going to work; it is very likely that many runtime failures will be triggered. OTOH, removing a null exclusion or adding a null exclusion to an anonymous access type will happen frequently. In all of these cases, the checks that change are runtime checks. The additional of "accept null" would have no impact on these runtime checks; the only cases were additional compile-time safety would occur is on subtypes of access types. These are very rare, and it seems that coding standards and/or restrictions identifier(s) could be used to avoid problems with implicit inheritance of null exclusions. (That is, require that null exclusions be repeated on subtypes for null excluding types; style checkers and/or a restriction could enforce that). Similarly, it would be useful if the confusing (but required for compatibility) controlling access parameter could be detected and banned in new code. Again, the best way to do that would be to have a restriction identifier that banned "implicit" null exclusions. Something like No_Implicit_Null_Exclusions If the subtype_mark of a subtype_indication excludes null, a null_exclusion shall be included in the subtype_indication. All controlling access parameters shall include an explicit null_exclusion. This restriction applies only to the current compilation or environment, not the entire partition. Conclusion: This proposal requires major rewording of the standard, provides no significant additional capabilities (and the suggested Restriction would provide the missing capability), and comes way too late in the process for such a significant change. --- ARG: Is additional compile-time checking worthwhile for null excluding subtypes? Should we add a restriction similar to the one proposed above? Or should we leave the best way to use this feature to the community to decide (via style guides, style tools, and the like)? ************************************************************* From: Jean-Pierre Rosen Sent: Friday, February 3, 2006 1:38 AM > ARG: Is additional compile-time checking worthwhile for null excluding > subtypes? Should we add a restriction similar to the one proposed above? Or > should we leave the best way to use this feature to the community to decide > (via style guides, style tools, and the like)? > It could be done, but that does not mean it should be done. Too much overkill for too little benefit for my taste. ************************************************************* From: Pascal Leroy Sent: Friday, February 3, 2006 3:46 AM I am generally not too excited about restrictions that are purely stylistic: clearly No_Implicit_Null_Exclusions would be one of those. It would not add any safety and it would not improve the generated code. Its only effect would be on legibility. And even so I am unconvinced by the definition you give: I can see the benefits for controlling parameters, but the notion of repeating "not null" on every subtype sounds bogus to me: we don't require that you repeat constraints on every subtype, for instance. I'd rather leave it to code rule checkers to enforce this kind of rules. And we can always add the restriction later if we discover that there is a strong demand from the community. ************************************************************* From: Tucker Taft Sent: Friday, February 3, 2006 7:09 AM About the only change I might consider in this area is to allow "'Base" to apply to access subtypes, as a way to recover the null including, unconstrained subtype, if the first subtype is null excluding. Other than 'Base, we don't have a way of de-constraining subtypes, and "accept null" would essentially be a way of de-constraining something. As far as the "No_Implicit_Null_Exclusions" that is a restriction that an implementor could add if there is demand for it. No need to pre-standardize that one at this point. ************************************************************* From: Pascal Leroy Sent: Friday, February 3, 2006 7:38 AM That crossed my mind, but remember that an access subtype can have both a constraint and a null exclusion. But then there is the question of whether the 'Base attribute only drops the null exclusion, or both the null exclusion and the constraint. If the former, we are left with a base subtype which is constrained, and that's strange. If the latter, I fear we go back to the Ada 83 mess with the Base attribute. This might be worth considering in the future (after all we can add this attribute compatibly at any time) but it seems too late for such a change. ************************************************************* From: Tucker Taft Sent: Friday, February 3, 2006 8:09 AM To me there is only one "base subtype" and it would include nulls and be unconstrained. Can you remind me what was the Ada 83 mess with the Base attribute? I remember problems relating to composite types, but none relating to access types. ************************************************************* From: Pascal Leroy Sent: Friday, February 3, 2006 8:22 AM I would have to do some archeology, but I was under the impression that access-to-composites had problems similar to composites. Maybe just FUD... ************************************************************* From: Tucker Taft Sent: Friday, February 3, 2006 11:27 AM My memory of the problem of 'Base on composites is that if the first subtype of a derived composite type is constrained, then it is possible to create a record rep clause that works for the first subtype, but requires a bizarre and unsupported representation for an unconstrained subtype. I don't see that this would apply to an access-to-composite subtype, since the designated subtype must be unconstrained in the first place if you can apply a constraint to an access type. So I *think* 'Base on an access subtype would be well defined, and could be useful, especially in a generic, to be able to declare null-including temporaries of a generic formal null-excluding access type. But hardly anything earth-shattering, and probably not compelling enough for a change at this point. ************************************************************* From: Robert A. Duff Sent: Friday, February 3, 2006 2:06 PM > ARG: Is additional compile-time checking worthwhile for null excluding > subtypes? Should we add a restriction similar to the one proposed above? Or > should we leave the best way to use this feature to the community to decide > (via style guides, style tools, and the like)? I'll say the same thing I said about "Case sensitivity in Directories, Environment_Variables": This proposal has technical merit but, I think it's way too late for this sort of thing. Note that we would have to argue about "accept null" vs. "with null". ARG can always address these kinds of issues after the standard is standardized. ************************************************************* From: Pascal Leroy Sent: Saturday, February 4, 2006 4:11 AM > Note that we would have to argue about "accept null" vs. "with null". Just for the record, I would much prefer Tuck's idea of extending the Base attribute, than inventing special syntax. The Base attribute seems more consistent with the existing language, and it can be added later with much less disruption. ************************************************************* From: Robert Dewar Sent: Monday, February 6, 2006 2:00 PM >> ARG: Is additional compile-time checking worthwhile for null excluding >> subtypes? Should we add a restriction similar to the one proposed >> above? Or >> should we leave the best way to use this feature to the community to >> decide >> (via style guides, style tools, and the like)? >> > > It could be done, but that does not mean it should be done. > Too much overkill for too little benefit for my taste. I agree, this is unnecessary (of course if Canada wants to spend a silver bullet on this, we can reconsider :-) ************************************************************* From: Robert Dewar Sent: Monday, February 6, 2006 2:01 PM > Note that we would have to argue about "accept null" vs. "with null". I far prefer "with null" if we do add either. ************************************************************* From: Robert Dewar Sent: Monday, February 6, 2006 8:14 PM >> It could be done, but that does not mean it should be done. >> Too much overkill for too little benefit for my taste. > > I agree, this is unnecessary (of course if Canada wants to > spend a silver bullet on this, we can reconsider :-) See my future notes on this, where I changed my mind on this issue. I am now in favor of changing the name. ************************************************************* From: Randy Brukardt Sent: Monday, February 6, 2006 8:33 PM Careful: there are three unrelated comments that I asked about. You commented on a message about "null inclusion" (and it appeared that is what you were talking about in this old mail). Your more recent notes are on Ada.Directories.Rename - I don't think you changed your mind on "null inclusion". ************************************************************* From: Robert Dewar Sent: Monday, February 6, 2006 8:33 PM My mistake, got threads mixed up (and was indeed surprised when I saw dewar-1 making an odd comment that dewar-2 disagreed with). Summary: move issue, I think the name should be changed Null inclusion: seems overkill, i agree no change here. ************************************************************* From: Robert Dewar Sent: Monday, February 6, 2006 11:26 PM dewar-2 is also having second thoughts about this one. It continues to bother me that we have introduced a serious incompatibility in Ada 2005 in this area (previously correct programs silently converted to be erroneous in Ada 2005). If we adopated the Canadian proposals it would provide an effective method to guard against the consequences of this incompatible change. ************************************************************* From: Randy Brukardt Sent: Monday, February 6, 2006 11:50 PM Would you care to elaborate? I'm not sure I see what help the extra, optional, keywords would be. You'd still have to put them in, and if you did that, you wouldn't have a problem (because you would put "not null" into existing code). The problem seems to mainly be one of backward compatibility: if you want your code to be both Ada 95 and Ada 2005, you have a problem because you can't get consistent behavior in both versions. (Otherwise, converting permanently to Ada 2005 can be automated: simply add "not null" to every access parameter. Probably an ASIS tool would have no problem doing that.) Adding more keywords won't help that - if anything it would make it worse. So what am I missing? ************************************************************* From: Robert Dewar Sent: Tuesday, February 7, 2006 12:11 AM If you have a config pragma that requires the keywords, then you can guarantee that no bad situations get carried forward on a port, or get introduced after the port. We have a serious case of incompatibility here, so it is useful to have a compiler option that makes it *really* incompatible, forcing the change. Your note above says that you can do the change manually. Fine, but it is useful to be able to force it. Without this feature there is no way to tell if (A : access Integer) is a not null case that someone forgot to label on the port, or accidentally introduced after the port, forgetting the incompatiblity. with the pragma in place, this is illegal, and you are forced to write either (A : not null access integer) or (A : with null acess integer) or whatever the syntax is ... and the potential mistakes that can come from the (really horrible) incompatible change are mitigated. ************************************************************* From: Robert Dewar Sent: Tuesday, February 7, 2006 12:13 AM > if you want your code to be both Ada 95 and Ada 2005, you > have a problem because you can't get consistent behavior in both versions. Due to this incompatible change, it is IMPOSSIBLE to have code that is both Ada 95 and Ada 2005. This is horrible, but true regardless of whether these new keywords are introduced. What a nasty mess! ************************************************************* From: Tucker Taft Sent: Tuesday, February 7, 2006 1:16 AM > Due to this incompatible change, it is IMPOSSIBLE to have code > that is both Ada 95 and Ada 2005. This is horrible, but true > regardless of whether these new keywords are introduced. I feel like we plowed this ground pretty thoroughly before, and I don't see the Canadian proposal helping significantly. > What a nasty mess! The incompatibility is that for non-controlling access parameters, if you don't add a not-null (in other words, retain the Ada 95 code as is), then you will now be able to pass null. But the existing code presumably doesn't do that. So the only "incompatibility" would be new code that takes advantage (intentionally or not) of the new permission. But this new code is likely going to be slipping into other Ada 2005'isms, so it probably won't remain backward compatible anyway. If you definitely want to be able to use both an Ada 95 and an Ada 2005 compiler interchangeably, then clearly you don't want to take advantage of passing null. If want that to be checked, then a possible thing to do during the transition period is to add in the subprogram's declarative part, for every non-controlling access param of the form "Param: access Desig" a rename at the beginning of the subprogram: Deref : Desig renames Param.all; This will fail with a Constraint_Error in Ada 2005 if the caller passed in a null. The same exception handler will handle the error as in Ada 95, presuming these renames are in the outermost declarative part of the subprogram. ************************************************************* From: Robert Dewar Sent: Tuesday, February 7, 2006 1:23 AM > The incompatibility is that for non-controlling access > parameters, if you don't add a not-null (in other words, > retain the Ada 95 code as is), then you will now be > able to pass null. But the existing code presumably doesn't > do that. Existing code may rely on an exception from trying to pass null. > > Deref : Desig renames Param.all; > > This will fail with a Constraint_Error in Ada 2005 if the > caller passed in a null. The same exception handler will > handle the error as in Ada 95, presuming these renames are > in the outermost declarative part of the subprogram. > interesting kludge. Worth a note at least in the AARM. But I see the Canadian proposal as valuable for making the code transition to Ada 2005, not trying to maintain compatibility with Ada 95. ************************************************************* From: Stephen Michell Sent: Tuesday, February 7, 2006 8:09 AM There has been a lot of discussion about this comment, but the basic fact is that there is an incompatibility which needs improvement. Our proposal (accept null) is along the lines of the "overriding/not overriding" discussion that led to the addition of a keyword. We think that the issue is important from the incompatibility and the documentation perspective. In our discussions that led to this comment, we were not married to "accept null", we were simply searching for a compound keyword that would match the intent. "with null" would probably be acceptable also. ************************************************************* From: Robert A. Duff Sent: Tuesday, February 7, 2006 3:52 PM How about "not not null". ;-) ;-) ************************************************************* From: Tucker Taft Sent: Tuesday, February 7, 2006 4:06 PM I think this is overkill for a minor incompatibility. We have generally not worried about incompatibilities that remove the raising of predefined exceptions, as handling such exceptions and presuming they are raised "precisely" is generally considered "bad form." I realize that *any* incompatibility can be cause for concern, but we have to be very careful that the cure is not worse than the disease. In this case, I think the cure will make the language more confusing and more complex, with relatively small, transient benefit. Providing 'Base on access subtypes would be a very minor change and provide some additional degree of uniformity, if it is felt to be essential to emphasize the lack of a null exclusion. Even that seems overkill in my view, especially at this late date. But it would be a more consistent and appropriate "fix" if one is felt essential. ************************************************************* From: Randy Brukardt Sent: Tuesday, February 7, 2006 4:16 PM > There has been a lot of discussion about this comment, but the basic fact is that > there is an incompatibility which needs improvement. Our proposal (accept null) > is along the lines of the "overriding/not overriding" discussion that led to > the addition of a keyword. We think that the issue is important from the > incompatibility and the documentation perspective. Well, this proposal does nothing whatsoever for the incompatibility, because "with null" and the current syntax of saying nothing would have the exact same semantics. (I'm assuming that "widening" subtypes are banned with appropriate legality rules.) There are only two states here! That's not true with "overriding"/"not overriding"; there are *three* states: "O", "~O", and "don't care". There's no "don't care" here, because "don't care" and "with null" have identical semantics. The only way to fix the incompatibility is to totally abandon the existing "access T" syntax. Indeed, we originally did that: access all T access constant T not null access all T not null access constant T where the original access T is equivalent to "not null access all T" and it is moved to Annex J. The reason we didn't do that was that users thought that the new syntax was too wordy, and they (specifically AdaCore people) thought that everyone would use the shortcut anyway, *and* it ould be confusing. I would expect that same comment to apply to other unnecessarily wordy syntax as well. That is, no one will use "with null access T" because it takes up too much space. So why bother? In any case, I would object to just trying to band-aid this. We need to go back to first principles if the current solution is not considered acceptable. Particularly if the band-aid doesn't fix the problem. My big objection to the current rules is the *lack* of explicit "not null" on controlling parameters. I'd prefer to allow "not null" in Ada 95 compilers (for backward compatibility) and then *require* it in controlling parameters (thus getting errors if the parameters aren't changed. That's quite incompatible (in the sense that correct Ada 95 code won't compile), but this is a mechanical change. ************************************************************* From: Stephen Michell Sent: Thursday, February 9, 2006 10:28 AM I am attaching additional info from Brad. He has been examining the connection with Generics also, as you can see when you read his notes. Randy's comments that this is 3-option as opposed to overriding's 2-option is false. The third option in overriding is that you don't use either and get the Ada95 behaviour. Canada is not going to use a silver bullet (or even a wooden stake) on this. We will live by the ARG's judgement (and of course I have to vote). --- Note: This discussion is derived from the paper by John Barnes, Rationale for Ada 2005, section 5 on Exceptions and Generics. Examples and text were taken and either directly copied or modified from that document. There are further cases that can be made in support for adding explicit null inclusion syntax to Ada. First of all, consider the syntax; type Ref_ANT is access T; type Ref_NNT is not null access T; type Another_Ref_NNT is new access Ref_NNT ; -- Excludes null According to the current proposal for Ada 2005, there is a rule that states that a type derived from a type that excludes null also excludes null. There are two issues to look at here. First of all, looking just at the declaration for the derived type which can be physically located in a different package than the base type, one cannot determine if the type includes null or excludes null. If someone changes the null inclusion indicator of the base type it affects the derived type and could lead to unexpected consequences for the derived type. It could be a recommended practice to explicitly state in the derived type whether or not the derived type excludes null or not as in; type Another_Ref_NNT is new not null access Ref_NNT ; -- Excludes null That way, changes to the null exclusion indicator of the base type would not affect the derived type. For the same reason it would be useful to write; type Another_Ref_ANT is new accept null access Ref_ANT ; -- Includes null This would insulate the derived type from changes to the base type. Also, if we maintain the current language syntax whereby we cannot derive a type that includes null from a type that excludes null, the compiler could flag this error at compile time. Without this syntax, using an implicit null inclusion, any problems associated with changing the base type on the derived type would likely not get caught until run time. Note that the language currently does not support deriving a new type that includes null from a type that excludes null. This might be a useful feature to add to the language, although it would be a bit of a departure in some ways from the existing language syntax whereby new types can be created that add constraints to existing types, but cannot remove constraints. On the other hand, null exclusion is not meant to be considered as a constraint according to the proposed languages specification. In other words, should it be possible to write a statement such as; type Ref_DANT is new accept null access Ref_NNT ; -- Should this be legal? For example, perhaps the rule should be changed to state that a type derived from a type that excludes null does not excludes null unless explicitly stated such as type Another_Ref_DANT is new access Ref_NNT; -- Includes Null type Another_Ref_DNNT is new not null access Ref_NNT; -- Excludes null One advantage of this approach is that one can tell whether or not a derived type includes or excludes null simply by looking at the declaration for the derived type. Coming up with an answer to these questions are likely to be a source of debate. However, whether or not such the language allows deriving a type that includes null from a type that excludes null does not impact the usefulness of being able to explicitly declare whether a type can include or exclude null. It probably makes the most sense to disallow deriving a type that includes null from a type that excludes null from the consistency standpoint and to minimize changes to the language, especially considering the current timeline in the Ada 2005 standard approval process. Note however that; type New_Ref_ANT is accept null access T; -- Includes Null type New_Ref_NNT is new not null access Ref_NNT; -- Excludes null Should be allowed, since there is no reason for disallowing this, and because the language currently supports deriving a type that excludes null from a type that includes null. Now consider generic units. There are inconsistencies in the language that can be alleviated by adding explicit null inclusion. In the current Ada 2005 syntax we allow formal access type parameters of the form; generic ... type A is not null access T; ... Where the actual type corresponding to A must then itself be an access type that excludes null. A similar rule currently applies in reverse - if the formal parameter excludes null then the actual parameter must also exclude null. With the addition of null inclusion we would also then be able to write; generic ... type B is accept null access T; ... From the rules mentioned above for the first form, it follows that the actual type corresponding to B must then itself be an access type that includes null. Furthermore, a similar rule would also apply in reverse, that is, if the formal parameter includes null then the actual parameter must also include null. This is a clean symmetrical syntax, which is desirable. In the case of the original Ada syntax; generic ... type B is access T; The existing syntax remains backwards compatible with Ada 95, where this form is generally considered a short form for the explicit accept null syntax above. An asymmetry in the syntax occurs when we consider when anonymous access types are now used for generic formal parameters. This asymmetry can be alleviated through the use of explicit null inclusion For example, we could write; generic A: access T := null; AN: in out not null access T; AA: in out accept null access T; F: access function (X: Float) return Float; FN: not null access function (X: Float) return Float; FA: accept null access function (X: Float) return Float; Currently, in the proposed Ada 2005 syntax, If the subtype of the formal object excludes null (as in AN and FN) then the actual must also exclude null but not vice versa. This contrasts with the rule for formal access types discussed above in which case both the formal type and actual type have to exclude null or not. According to the proposed standard, A and F above might exclude null or might not. With explicit null inclusion, this could be interpreted as an indication that stronger type checking is desired and that the actual generic parameters cannot exclude null. This provides a more symmetrical view to match the case for null exclusion so that we now can state; 1)If the subtype of the formal object excludes null (as in AN and FN) then the actual must also exclude null 2)If the subtype of the formal object explicitly includes null (as in AA and FA) then the actual must also include null either explicitly or implicitly. 3)If the subtype of the formal object implicitly includes null (as in A and F), then the actual can either exclude null or include null. The ability to explicitly specify null inclusion leads to improved efficiency in the generic code and improved safety and security. If we explicitly specify accept null for a generic formal object, then the generic code would not need to check for null internally. Without accept null, the code needs to check for null since a type that excludes null can be passed into the generic into a parameter that includes null. Also, the generic could conceivably pass a reference to a generic parameter to a library function that sets the access type variable to a null value. This could lead to run time errors that could have been caught at compile time. If the writer of the generic knows that null values could get assigned to access variables, the writer of that generic could specify accept null on that generic parameter which would force the user of the generic to pass in a type that does not exclude null. Similarly, if the subprogram profile itself has access parameters that exclude null as in; generic PN: access procedure (AN: not null access T); then the actual subprogram must also have access parameters that exclude null. The same rule applies to named formal subprogram parameters. If we have; generic with procedure P(AN: not null access T); with procedure Q(AN: access T); then the actual corresponding to P must have a parameter that excludes null but the actual corresponding to Q might or might not. If we could write generic PAN: access procedure (AN: accept null access T); Or; generic with procedure R(AN: accept null access T); We would have a way to specify that the actual subprograms have access parameters that must include null. The implicit declaration would remain as before where the actual parameter may or may not exclude null. This provides similar improvements for efficiency, safety and security as mentioned above, yet provides the flexibility to accept parameters that can either include or exclude null. As a final note, consider that there are cases where it is not possible to explicitly indicate null inclusion or exclusion. Suppose we have; generic type T is private; with procedure P(Z: in T); package G is This can be matched by type A is access ...; procedure Q(Y: in not null A); ... package NG is new G(T => A; P => Q); Note that since the formal type T is not known to be an access type in the generic declaration, there is no mechanism for applying a null exclusion to it. Nevertheless there is no reason why the instantiation should not be permitted. This means that we still need to be able to rely on implicit null inclusion. In other words we could not have the compiler force the programmer to always explicitly specify whether the parameter excludes null or not. There are times when the programmer might want a type derived from a base type to have the same null inclusion/exclusion specification. The implicit declaration remains a way to do this. In summary, this proposal for explicit null inclusion provides more flexibility for the programmer, improved efficiency, and improved safety and security. All are important considerations for the overall design goals of Ada. ************************************************************* From: Randy Brukardt Sent: Thursday, February 9, 2006 3:27 PM > Randy's comments that this is 3-option as opposed to overriding's 2-option > is false. The third option in overriding is that you don't use either > and get the Ada95 behaviour. You have my statement backwards. I said that overriding is the 3-option case: overriding, not overriding, "don't care" - the Ada 95 option. The original proposal you sent only has two states: "not null" and "accept null"/nothing, because there was no special semantics associated with "accept null". There isn't much point in having two syntaxes for one state; that's something we've tried to avoid. ************************************************************* From: Randy Brukardt Sent: Thursday, February 9, 2006 4:22 PM > I am attaching additional info from Brad. He has been examining > the connection with Generics also, as you can see when you read his notes. I suspect that this issue comes down to how you expect null exclusions to be used. I think that they will be primarily useful in parameters and discriminants (both for anonymous and named subtypes). And occasionally useful for stand-alone objects. As such, it will almost always be used directly in the parameter, discriminant, or object declaration: Param : in not null My_Access; Other_P : access not null Typ; Obj : not null My_Access; That has the best readability. I think named subtypes will be rare, and types will be exceedingly rare. (The latter because you can't use Unchecked_Deallocation with them.) Named subtypes would have to include "not_null_" or some equivalent in the name in order to keep the readability up, at which point there is no real benefit to the named subtype. Note that most of issues that Brad talks can't even exist without named subtypes. For instance, he says: > According to the current proposal for Ada 2005, there is a rule that > states that a type derived from a type that excludes null also > excludes null. There are two issues to look at here. First of all, > looking just at the declaration for the derived type which can be > physically located in a different package than the base type, one > cannot determine if the type includes null or excludes null. If > someone changes the null inclusion indicator of the base type it > affects the derived type and could lead to unexpected consequences for > the derived type. Since it will be very rare to even have a named subtype with a null exclusion, it seems even more unlikely to be deriving a type from such a thing. (And, as previously mentioned, such a type would be nearly useless, as it couldn't use Unchecked_Deallocation. Even if it existed, it probably wouldn't survive long.) It's also the case, of course, that Ada derived types work this way for everything else: type AINT is range 0 .. 100; type Another_AINT is new AINT; -- Has range 0 .. 100 And certainly a AINT could be far away, a change could have unexpected consequences, etc. Moreover, this is often what you want: derived types are often used as a poor-man's rename, and you *want* to inherit all of the characteristics. The same goes for generic formal objects (the constraint comes from the actual object, not the subtype given in the generic -- the generic body shouldn't depend on any particular constraint), and parameters of generic formal subprograms (the constraints come from the actual, not the formal subtypes). Ada 2005 actually goes beyond the Ada norm and tries to provide some checking in these cases. But it should be clear that it is the checking that is anomalous, not the notion that it doesn't go far enough. The obvious solution to these complaints is to revert to the Ada 95 rules (no checking at all), which would be more consistent with the rest of the language. Anyway, if you think that there will be a lot of use of null exclusions outside of parameters, you might be concerned about the Ada 2005 rules. But I think that few users will ever run into these cases, and fewer in ways that would matter. Note that Brad's note seems to imply a number of changes to legality rules: for renames, for generic matching, for static matching, for derivation, for parameters, etc. The proposal that was submitted did not include any of these rule changes, and thus there was no additional checking in the proposal. That may have contributed to the reaction to it. The good thing about this proposal is that it appears fully compatible (in that no changes in the behavior of access types with no exclusion or inclusion are made), so that it could be added in the future without a problem. That means that if we decide not to add it now, it still could be added in the future. ************************************************************* From: Stephen Michell Sent: Friday, February 10, 2006 8:26 AM My understanding of the current situation is that if you derive from a "not null" construct, you do not need to say "not null" again, so you get what the original one was, but you don't know it unless you go to the root and check, so it is also ambiguous. ************************************************************* From: Robert Dewar Sent: Friday, February 10, 2006 8:36 AM > The phrasing of the question made it impossible to answer. The issue is not what most > programmers would use it for, but what serious projects would demand. My position is that, > just like "overriding" and "not overriding", serious projects would put in place a coding > rule that you must use "not null" or "accept/with null" for all access types that you > declare to prevent unforseen clashes and use the compile time checking to improve the code. By the way, it is this important usage (a coding restriction of the kind mentioned above) that makes the proposal useful, and thus Tucker's proposal is completely irrelevant as a "solution" to the problem that I see as needing to be solved, which is to avoid problems caused by this nasty incompatibility. Why is this incompatibiliy nasty? Because in moving to Ada 2005, everyone will ask: "is Ada 2005 upwards compatible with Ada 95". It would be nice to answer yes! Well we can't quite do that anyway because of new keywords, so the answer we would like is "almost completely, and those few cases of incompatibility that exist, the compiler will always diagnose the problem." well we can't even do that, because of the wide character changes, so perhaps "almost completely, with two exceptions. There are some new keywords so the compiler will diagnose any misuse of these and the problem is easily fixed. Also there are some changes in the handling of wide characters, which won't affect anyone not using this feature, and which furthermore almost certainly fix previous problems rather than create new problems." But the null access point is something that is much more delicate, we have to add Finally, the meaning of access parameters has been changed. This can silently affect the behavior of existing programs, even resulting in the appearence of erroneous execution. You will have to carefully check every use of access parameters and add NOT NULL wherever the program is counting on this. You can just add these keywords unconditionally to all current Ada 95 usage, and then you are guaranteed unchanged behavior in Ada 2005." This last advice would be more convincing if a) we allowed the keywords to be added in Ada 95 mode that's an absolute minimum in my view b) we allow the WITH NULL (or whatever) alternative, so that we can avoid mistakes being introduced by Ada programmers who are not sufficiently aware of this significant change in the language. As Steve said, the idea would be to have a coding requirement (possibly enforced by a standard pragma) that would force you to write NOT NULL or WITH NULL. Then any programmer not knowing about this issue would leave out the keywords, get a rejection and be forced to find out about the issue and make the proper choice. For consistency, one might consider allowing WITH NULL on any access type (after all it was worrying about consistency that lead to the decision to tolerate a worst-case non upwards compatibility) [worst case here does not refer to the likelyhood of this causing trouble, but rather the fact that it is the kind of incompatibility that silently causes a difference in behavior). One aspect that I think sometimes the ARG does not sufficiently well understand is that many Ada users are dealing with huge programs that they do not know well. They are interested in the possibility of using some Ada 2005 features in a conservative manner, but an incompatibility of this nature is going to really worry some users. We see the same phenomenon when we notify people of a highly obscure bug in the compiler. We know that in practice it is not going to occur in existing programs, but people worry about how they can make sure of this. I also don't think people want a precipice effect, that the transition to Ada 2005 means making source modifications that make it impossible to return to Ada 95. That's why officially allowing NOT NULL in Ada 95 programs is important. Yes, of course compiler writers can allow this under some switch, but many of the same users are also nervous about using special switches that corresond to non-standard behavior. So blessing the possibility of putting NOT NULL in Ada 95 programs will in practice be a big help in dealing with this problem. After all, if we go just this far, people could have a coding standard that required the use of NOT NULL in *all* access parameters all the time. They would not be able to take advantage of the marginal value of the new feature in Ada 2005, but that's not so terrible, and may seem a lot better than risking wandering into incompatibility territory. ************************************************************* From: Robert A. Duff Sent: Friday, February 10, 2006 9:01 AM > a) we allowed the keywords to be added in Ada 95 mode > > that's an absolute minimum in my view I agree. Especially if the compiler writers around here commit to doing so. ************************************************************* From: Randy Brukardt Sent: Friday, February 10, 2006 1:38 PM I third this notion. In fact, I would suggest that we pass a resolution suggesting that the ACAA issue an ACATS test for this (that needs a resolution because WG 9 has suggested that the ACAA not issue new Ada 95 tests; additionally, a resolution would allow adding the test immediately, without the normal waiting period), and thus we would encourage *all* compilers to support this ASAP. That, plus agreement from the vendors here, would get this done at "the speed of light"; most users would have the capability in their hands by the end of the year. (Users that don't update compilers aren't going to be transitioning to Ada 2005 anyway.) To this point, the vote on the letter ballot on this question was 5-2-4; that's not a clear consensus, but it seems that we lean toward allowing the keywords in Ada 95. Perhaps we can figure out a way to build consensus on this issue. Those of you that are against this or abstained: what's the concern? Can it be addressed? This is a semantic-free proposal, after all. ************************************************************* From: Tucker Taft Sent: Friday, February 10, 2006 2:32 PM I believe I explained my abstention -- I didn't think it mattered, since vendors can do this if they want today. I am quite happy to go along if others feel strongly, since I see absolutely no harm in doing this, except perhaps expecting too much from it. ************************************************************* From: Gary Dismukes Sent: Friday, February 10, 2006 3:19 PM But they can't necessarily do it with a clear conscience, which is why it would be better to have an official blessing. :-) Also, it would be nice if all vendors would agree to do this to aid portability. ************************************************************* From: Robert Dewar Sent: Friday, February 10, 2006 4:35 PM > But they can't necessarily do it with a clear conscience, which > is why it would be better to have an official blessing. :-) I think this misses the point. They can't do it except under a non-standard switch, and many customers have a policy of avoiding anything that is officially non-standard. > > Also, it would be nice if all vendors would agree to do this > to aid portability. Well I think whether vendors follow something like this is up to them and their judgment of what the market requires. You could also say it would be nice if all vendors would agree to get their compilers validated to aid portability, but in fact no vendor is bothering with validation at the moment, since there simply is not a market demand for formal validation (at least we don't see any!) ************************************************************* From: Robert Dewar Sent: Friday, February 10, 2006 4:54 PM > That, plus agreement from the vendors here, would get this done at "the > speed of light"; most users would have the capability in their hands by the > end of the year. (Users that don't update compilers aren't going to be > transitioning to Ada 2005 anyway.) You certainly have the agreement of AdaCore. We actually implemented this based on the earlier AI, and then removed the implementation when the ARG changed its mind. ************************************************************* From: Robert Dewar Sent: Friday, February 10, 2006 4:58 PM > I believe I explained my abstention -- I didn't > think it mattered, since vendors can do this if > they want today. I am quite happy to go along > if others feel strongly, since I see absolutely > no harm in doing this, except perhaps expecting > too much from it. All I expect is that I will be able to tell my users the following: One incompatibility that has to be checked is the change in the meaning of access parameters. In Ada 95, you could count on them being non-null (and CE being raised on an attempt to pass null). In Ada 2005, by default access parameters do permit null. This is generally much more convenient, but does result in possible incompatible behavior. In Ada 2005, you can solve this problem by labeling your access parameters as NOT NULL, resulting in Ada 95 compatible behavior. As a preparation to making a transition to Ada 2005, you can ensure that this incompatibility by labeling all existing access parameters NOT NULL and in fact we provide a tool for making these changes to your sources automatically. To aid this transition, the NOT NULL keywords are now allowed in Ada 95 mode now (this is an official change to the Ada 95 language), so if you do this, you will still be able to compile in Ada 95 mode (assuming that the Ada 95 compiler you use respects this latest change, which GNAT Pro most certainly does). ************************************************************* From: Pascal Leroy Sent: Monday, February 13, 2006 11:08 AM You'll find below the results of the letter ballot on the Canadian proposal. I am only including the numerical results, not the comments that came with the votes, as you have seen them already. The results of multiway, non-independent votes are always hard to interpret, but someone has to do it, so here are my conclusions: 1 - There is a clear consensus against changing the syntax/semantics of anonymous access types as proposed by the Canadian delegation. 2 - There is a majority in favor of allowing "not null" in Ada 95. 3 - The documentation benefits of "accept null" (or whatever the syntax) are felt to be insufficient. 4 - The syntax "with null" is preferred over "accept null" (but this is pretty irrelevant given the result for question 3). 5 - Widening of subtypes is considered unpleasant. 6 - The potential confusion regarding controlling parameter is not that bad. 7 - We have no idea whether people would use optional syntax consistently or not (bad experience with "in" parameters?). 8 - Tuck's 'Base idea has some appeal. 9 - It is very much unclear whether Tuck's 'Base idea would actually solve the problems raised by the Canadian delegation. These results lead to the following action items: Randy: Proceed with the preparation of draft 16 of the Amendment *without* including the Canadian proposal on null inclusion. Randy: Prepare a BI for consideration at the Oporto meeting to allow "not null" in Ada 95. (Since this is a change to Ada 95, it doesn't impact the Amendment, so it can wait until the next meeting.) Tuck: Prepare an AI for consideration at the Oporto meeting to allow 'Base for access types. Pascal -- Voting: Baird, Barnes, Brukardt, Burns, Dewar, Dismukes, Duff, Eachus, Leroy, Michell, Ploedereder, Rosen, Taft, Tokar. 1) Should the syntax and semantics of anonymous access types be revisited to reduce or eliminate the incompatibilities introduced for access parameters? ___ Yes, the incompatibility is critical, it must be eliminated. _2_ Yes, the incompatibility is important, but other considerations also apply. _1_ No, the incompatibility is unlikely to matter in practice. 11_ No, the incompatibility isn't that serious and the delay in the Amendment required to revisit (at least 6 months) is unacceptable. 2) One proposed way to mitigate the compatibility problem is to allow "not null" in access parameters and discriminants (optionally) in Ada 95 programs. (The meaning would be the same whether or not it is present.) That way, users could write code now that won't have problems on porting. _8_ Yes, allow "not null" in Ada 95 programs. _2_ No, do not allow "not null" in Ada 95 programs. _4_ Abstain 3) Canada suggests adding "accept null" to explicitly specify the opposite of null exclusion. Are the documentation benefits of this sufficient to add it? _3_ Yes. 11_ No. 4) If the Canadian proposal goes forward, which syntax would you prefer? _1_ "accept null" 12_ "with null" _1_ Abstain 5) The Canadian proposal allows subtype "widening", that is, for a subtype to be less constrained than its parent subtype. That's a new concept in Ada. Specifically, subtype Foo is not null Acc; subtype Bar is accept null Acc; Subtype Bar has more values than its parent, Foo. Should this be allowed? _1_ Yes, this is OK. _10_ No, Bar should be illegal. _3_ Abstain. 6) The intent of the Canadian proposal is to increase the possibility of compile-time checking for controlling parameters and (possibly) subtypes. Should the proposed Amendment be revisited to address this? _2_ Yes, controlling parameters are likely to be confusing. 11_ No, this isn't important enough for the time it would take. _1_ Abstain 7) Wordiness was the original reason for introducing the incompatibility; users felt that the old syntax "access T" was too convenient to abandon. Similarly, the optional "all" was dropped because it was felt no one would use it and it signified no semantics. The Canadian proposal would also increase the wordiness of access parameters when it is used. In your opinion, will users use the "accept null" syntax if it is added to the language? _1_ Yes, the added documentation is compelling. _5_ Maybe, it would be used like "in" for parameters: inconsistently. _6_ No, most programmers will use the shortest correct form. _2_ Abstain. 8) Tucker has proposed allowing 'Base on access subtypes to allow getting to an access subtype that is not encumbered with a null exclusion. This would allow the "widening" of the Canadian proposal without adding any new concepts. Is this worth doing? _2_ Yes, the ability to reach unconstrained access types would be useful. _8_ Yes, (as above), but this isn't important enough to do now. _1_ No. _3_ Abstain. 9) Is Tucker's proposal as outlined above a sufficient solution to replace the Canadian proposal? _4_ Yes. _4_ No. _6_ Abstain. ************************************************************* From: Robert A. Duff Sent: Wednesday, February 15, 2006 5:14 PM > A feature that is solely for documentation is no better than a comment. Pascal, I find it hard to believe that you really believe that! I'd go so far as to say that the _only_ important distinction between Ada and, say, assembly language is that Ada has features whose sole purpose is to document the intent of the programmer (as opposed to telling the machine what to do). Such "documentation" is far superior to comments, because it is likely true (unlike comments). I am in favor of the "with null" feature for this reason. I voted against it for the Ada 2005 standard, because I think it's too late, but (as I said before) I think the idea has technical merit, and should be discussed as a post-Ada-2005 AI. ************************************************************* From: Robert A. Duff Sent: Wednesday, February 15, 2006 5:20 PM > 1 - There is a clear consensus against changing the syntax/semantics of > anonymous access types as proposed by the Canadian delegation. > 8 - Tuck's 'Base idea has some appeal. > Tuck: Prepare an AI for consideration at the Oporto meeting to allow 'Base > for access types. Now wait a minute! The above seems to imply that the "with null" idea is dead in the water, whereas the Access'Base idea is to be considered in the future. My vote, at least, was not intended that way. I think both ideas should not be included in Ada 2005, but both ideas should be discussed post-2005. And, in fact, I prefer the "with null" idea over the 'Base idea (but I'm open minded, pending further discussion). ************************************************************* From: Randy Brukardt Sent: Wednesday, February 15, 2006 6:49 PM > The above seems to imply that the "with null" idea is dead in the water, > whereas the Access'Base idea is to be considered in the future. Well, certainly the votes suggest that. But of course everything will be on the table again at some future point. The only question is what to consider *now*, as immediate AI2005's. > My vote, at least, was not intended that way. I think both ideas should not > be included in Ada 2005, but both ideas should be discussed post-2005. Well, here I agree: both ideas should be discussed in the future, once we have experience in the use of "not null". Right now, the way I anticipate "not null" to be used, neither is more than a "nice-to-have". (Named null-excluding subtypes and especially types should be rare.) But I'll be the first to admit that I don't know how use will evolve over time. In any case, we shouldn't be messing with Ada 2005 (other than to fix clear bugs) before the ink is dry! I do think there is value to having the 'Base proposal written up. And, if you think "with null" is such a good idea, feel free to write up an AI on it, complete with *all* of the needed wording changes. It's wouldn't hurt for it to be on the record. But I intend to vote against any such AIs at this time: it's just too soon to be making changes. > And, in fact, I prefer the "with null" idea over the 'Base idea > (but I'm open minded, pending further discussion). This is confused, at best. Here, the vote is clear. "widening" subtypes is not going to fly (1-10-3 is about as clear as an ARG vote ever gets). So these two ideas are completely orthogonal to each other. (I don't understand the vote on question 9 for that reason - but I didn't want to bias the ballot.) 'Base is only about accessing the underlying access type that allows null (even for a null excluding type); "with null" is pretty much only about generic matching (it surely has nothing to do with compatibility - the Ada 95 AI will cover that). ************************************************************* From: Robert Dewar Sent: Wednesday, February 15, 2006 8:40 PM > Pascal, I find it hard to believe that you really believe that! I'd go so far > as to say that the _only_ important distinction between Ada and, say, assembly > language is that Ada has features whose sole purpose is to document the intent > of the programmer I agree with this sentiment (and share the surprise :-) ************************************************************* From: Robert Dewar Sent: Wednesday, February 15, 2006 8:41 PM > My vote, at least, was not intended that way. I think both ideas should not > be included in Ada 2005, but both ideas should be discussed post-2005. > And, in fact, I prefer the "with null" idea over the 'Base idea > (but I'm open minded, pending further discussion). I agree with this conclusion. ************************************************************* From: Robert A. Duff Sent: Wednesday, February 15, 2006 8:56 PM ... > In any case, we shouldn't be messing with Ada 2005 (other than to fix clear > bugs) before the ink is dry! Agreed. > I do think there is value to having the 'Base proposal written up. Agreed. >..And, if > you think "with null" is such a good idea, feel free to write up an AI on > it, complete with *all* of the needed wording changes. It's wouldn't hurt > for it to be on the record. But I intend to vote against any such AIs at > this time: it's just too soon to be making changes. Agreed -- "at this time". > > And, in fact, I prefer the "with null" idea over the 'Base idea > > (but I'm open minded, pending further discussion). > > This is confused, at best. Here, the vote is clear. "widening" subtypes is > not going to fly (1-10-3 is about as clear as an ARG vote ever gets). Well, I think I was one of those 10, but I think I've changed my mind. But I'll let that slide for now, pending future (post-Ada-2005) discussion. >... So > these two ideas are completely orthogonal to each other. (I don't understand > the vote on question 9 for that reason - but I didn't want to bias the > ballot.) 'Base is only about accessing the underlying access type that > allows null (even for a null excluding type); "with null" is pretty much > only about generic matching (it surely has nothing to do with > compatibility - the Ada 95 AI will cover that). Obviously, more discussion will be needed. ************************************************************* From: Randy Brukardt Sent: Wednesday, February 15, 2006 9:50 PM Seriously? Yuck. Part of the problem with "widening" with this proposal is that it eliminates the only thing I find attractive about it: the possibility for additional compile-time checking. I'm not interested in having a syntax that means different things in subtypes and in parameters (after all, that's the objection to the current rules, and it wouldn't do introduce something that has the same problems). ************************************************************* From: Pascal Leroy Sent: Thursday, February 16, 2006 5:02 AM > > A feature that is solely for documentation is no better than a > > comment. > > Pascal, I find it hard to believe that you really believe > that! I'd go so far as to say that the _only_ important > distinction between Ada and, say, assembly language is that > Ada has features whose sole purpose is to document the intent > of the programmer... Probably a poor choice of words on my part. Ada is about letting the programmer express her intent *AND*CHECKING* that all usages are consistent with this intent. My understanding of the "with null" proposal is that it doesn't involve any legality check (but I would have to see a full-fledged AI to know for sure). So the only benefit you get compared with a comment is the syntactic checking. You could not mistype it "with nul". Yawn. This is exactly similar to the optional "in" for in parameters. Do you really believe that it brings any value? I wish Jean had made up his mind to either force me to write "in" or prevent me from writing "in". The current state of affair is ludicrous. > I am in favor of the "with null" feature for this reason. I am opposed to the "with null" feature for the same reason that I dislike the situation with "in" for parameters. ************************************************************* From: Pascal Leroy Sent: Thursday, February 16, 2006 5:19 AM > Now wait a minute! > > The above seems to imply that the "with null" idea is dead in > the water, whereas the Access'Base idea is to be considered > in the future. Any idea can be considered in the future, including "out" parameters for functions ;-) I was not trying to manipulate the ARG in one way or another, but only to draw the conclusions from the vote. I only see minimal support for the "with null" idea, and I see some interest for the 'Base idea. So it seemed to me that it would be useful to have a write-up for 'Base, as a basis for discussion. Remember that I am not spending precious meeting time on ideas for which no AI was written. Of course, the same is true for "with null": if you think that this is a promising idea, by all means write an AI and I'll put it on the agenda on the next meeting (I would actually find it useful to know what exactly is this mysterious "with null" proposal). Note however that we should not rock the boat and introduce new features before the new language has got some mileage. After all, both users and implementers are going to be busy for some time digesting Ada 2005. Also, it's probably the case that 'Base would be easier to introduce incrementally in the language than "with null": features that affect the syntax tend to be more destabilizing. ************************************************************* From: Robert A. Duff Sent: Thursday, February 16, 2006 6:46 AM > Probably a poor choice of words on my part. > > Ada is about letting the programmer express her intent *AND*CHECKING* that > all usages are consistent with this intent. Right. > My understanding of the "with null" proposal is that it doesn't involve > any legality check (but I would have to see a full-fledged AI to know for > sure). So the only benefit you get compared with a comment is the > syntactic checking. You could not mistype it "with nul". Yawn. I agree -- that would be a yawn. But I envision using a coding convention that requires "with null" in certain well-defined cases. And some way to automatically enforce that convention, such as a pragma. If we could turn back the clock, I'd then make "not null" be the default, and eliminate the "not null" syntax. > This is exactly similar to the optional "in" for in parameters. Do you > really believe that it brings any value? I wish Jean had made up his mind > to either force me to write "in" or prevent me from writing "in". The > current state of affair is ludicrous. I agree 100% about "in". > > I am in favor of the "with null" feature for this reason. > > I am opposed to the "with null" feature for the same reason that I dislike > the situation with "in" for parameters. Without the above-mentioned pragma, I would agree. The pragma does not necessarily need to be language defined. ************************************************************* From: Pascal Leroy Sent: Thursday, February 16, 2006 7:23 AM > > This is confused, at best. Here, the vote is clear. "widening" > > subtypes is not going to fly (1-10-3 is about as clear as an ARG vote > > ever gets). > > Well, I think I was one of those 10, but I think I've changed > my mind. You must not be the real Bob Duff, you must be someone spoofing his address. The real Bob Duff has better taste than that. ************************************************************* From: Robert Dewar Sent: Thursday, February 16, 2006 7:29 AM > Ada is about letting the programmer express her intent *AND*CHECKING* that > all usages are consistent with this intent. pragma Restrictions (No_Recursion) ??? so we are not 100% consistent even with this principle (there are other examples). Note that confirming rep clauses are really just a case of comments for documentation as well. > My understanding of the "with null" proposal is that it doesn't involve > any legality check (but I would have to see a full-fledged AI to know for > sure). So the only benefit you get compared with a comment is the > syntactic checking. You could not mistype it "with nul". Yawn. Critically, it allows people to enforce a coding style in which the default (which to my mind is disastrously incompatible between Ada 95 and Ada 2005) is not used at all, thus avoiding the incomaptibility. This would be checked. Also code using WITH NULL for a parameter would not compile in Ada 95 mode, and the compiler *would* check this! > > This is exactly similar to the optional "in" for in parameters. Do you > really believe that it brings any value? I wish Jean had made up his mind > to either force me to write "in" or prevent me from writing "in". The > current state of affair is ludicrous. Well any reasonable coding standard makes a choice. Certainly no decently written Ada code mixes the two at random (see -gnatyI in GNAT Pro for example which enforces absence of IN). > I am opposed to the "with null" feature for the same reason that I dislike > the situation with "in" for parameters. The comparison is inapt. I agree with optional IN brings nothing. The optional WITH NULL would be very valuable in managing the nasty incompatibility between Ada 95 and Ada 2005 (I would prefer not to have introduced such a serious (*) incompatibility, but since we did, worrying about how to manage it is significant. (*) to me, any change that converts legal correctly operating programs to erroneous programs is an incompatibility of the worst possible kind. ************************************************************* From: Tucker Taft Sent: Thursday, February 16, 2006 7:55 AM We have generally had three categories, in increasing order of unpleasantness: 1) Incompatible, but not inconsistent (i.e. legal prog becomes illegal) 2) Inconsistent, but only if predefined exeception had occurred originally (i.e. legal prog that raises predefined excep no longer does so) 3) Inconsistent, including for cases where no predefined exception was raised (i.e. legal prog does something different, and it didn't raise an exception before) This one seems to be in category 2. Is there something about it that makes it worse than category 3, or other examples of category 2? Also, you are using the term "erroneous" above. Remind me of why you say that. Are you presuming that some but not all null-pointer checks are being suppressed? ************************************************************* From: Robert Dewar Sent: Thursday, February 16, 2006 8:09 AM > This one seems to be in category 2. Is there > something about it that makes it worse than > category 3, or other examples of category 2? I think so, see below > > Also, you are using the term "erroneous" above. Remind > me of why you say that. Are you presuming that > some but not all null-pointer checks are being suppressed? I am assuming that the caller is compiled with checks on (e.g. the normal case of an application program compiled in default mode), and the called program has checks off (common in libraries, where we have verified that no exceptions can be raised). This was the case in the GNAT run time, where we had to make some changes because of this, although now we compile the GNAT run time in Ada 2005 mode anyway, so that's water under the bridge, but I can see it happening in other cases of standard libraries. It definitely introduces an unsafe condition that did not exist in the Ada 95 program that was being ported. It is one thing to remove an exception by doing something sensible that does not cause difficulties. Here we have removed an exception, and passed on a junk value to the called routine which it does not expect. That seems worse to me than say removing a CE on an aggregate assignment because now we do proper sliding (that's more what case 2 has in mind) At this stage, I don't think it is feasible to fix this incompatibility, but anything that helps deal with it is welcome. So in order of usefulness 1. Allow NOT NULL in Ada 95 programs 2. Allow WITH NULL in Ada 2005 programs 3. Add a pragma for Ada 2005 that mandates the use of NOT NULL or WITH NULL. ************************************************************* From: Erhard Ploedereder Sent: Thursday, February 16, 2006 9:04 AM > Note that confirming rep clauses are really just a case of > comments for documentation as well. This is definitely, positively not true. A confirming rep clause mandates rejection of the program, if the rep clause does not confirm what the compiler does on its own volition. As such, it is a very useful check of user expectation vs implementation reality. I am struggling to imagine an example where "with null" might cause rejection of the program. (I could see this if anon.access types were namable.) It it much more like the "in" parameter mode. Its presence/absence carries zero static or dynamic semantics. To discuss a "zero semantics" feature in the final stages of a standardization process is a bit strange. The symmetry argument can only carry so far.... Type T is new Integer and not private and not limited; :-) ************************************************************* From: Robert Dewar Sent: Thursday, February 16, 2006 9:26 AM > This is definitely, positively not true. A confirming rep clause > mandates rejection of the program, if the rep clause does not > confirm what the compiler does on its own volition. As such, it > is a very useful check of user expectation vs implementation reality. No, they are often used just for documentatoin type R is (A, B); for R use (A => 0, B => 1); no rejection possible, none expected, and the rep clause is there ONLY for documentation purposes. This actually is a fairly common usage (Ada Magic initially forgot to special case this, and generated junk general-case enum rep code, fixed now :-) > > I am struggling to imagine an example where "with null" might cause > rejection of the program. (I could see this if anon.access types were > namable.) No, you have it wrong, the idea is that what you would reject (from a tool, coding standard, possibly enforced by a pragma) is NOT putting in WITH NULL! That's the whole point, once you are allowed WITH NULL, you insist on either NOT NULL or WITH NULL and do not allow the default case. Programs written in this way are either compatible with Ada 95 and Ada 2005, or they are illegal in Ada 95 *and will be rejected by the Ada 95 compiler* (which is not otherwise the case). WITH NULL may be documentation in Ada 2005, but it is (helpfully) illegal rubbish in Ada 95. ISO may think that Ada 95 disappears when Ada 2005 appears, but vendors and users disagree :-) > To discuss a "zero semantics" feature in the final stages of a > standardization process is a bit strange. The symmetry argument > can only carry so far.... It's not a symmetry argument. You can reject the argument, but at least make sure you understand it! :-) ************************************************************* From: Pascal Leroy Sent: Thursday, February 16, 2006 8:41 AM > pragma Restrictions (No_Recursion) ??? Not the most useful feature of the language if you ask me. Besides, checking is not required, but it is possible (at run-time, of course). > Note that confirming rep clauses are really just a case of > comments for documentation as well. Nonono, confirming rep clauses are essential to portability. A comment would not have exactly the same effect. > Critically, it allows people to enforce a coding style in > which the default (which to my mind is disastrously > incompatible between Ada 95 and Ada 2005) is not used at all, > thus avoiding the incomaptibility. This would be checked. I could be (mildly) interested by this kind of checking, but as I recall it was not part of the Canadian proposal. Anyway I have pretty much gotten convinced that discussing the "with null" idea without an AI is vacuous because we don't really know what this idea entails. > (*) to me, any change that converts legal correctly operating > programs to erroneous programs is an incompatibility of the > worst possible kind. I guess that this can happen whenever we have a change that causes a predefined exception to be raised in a different scope than it originally was. I am too lazy to check the "inconsistencies" sections of the AARM, but I'd be surprised if this were the only instance of such a change in the Ada 83/Ada 95/Ada 2005 history. Also, are there implementations where dereferencing the null value in unchecked code would do something other than dumping a core? To me, a core dump is nearly as good as an exception for the purposes of debugging. ************************************************************* From: Robert Dewar Sent: Thursday, February 16, 2006 12:12 PM > Nonono, confirming rep clauses are essential to portability. A comment > would not have exactly the same effect. yesyesyes, you are missing the kind of case I am talking about, sorry I thought it was obvious. Cases are type X is range - 2**31 .. + 2**31-1; for X'Size use 32; type M is (X, Y); for M use (0, 1); there are other cases, I am sure you can figure out other examples! >>Critically, it allows people to enforce a coding style in >>which the default (which to my mind is disastrously >>incompatible between Ada 95 and Ada 2005) is not used at all, >>thus avoiding the incomaptibility. This would be checked. > > I could be (mildly) interested by this kind of checking, but as I recall > it was not part of the Canadian proposal. Anyway I have pretty much > gotten convinced that discussing the "with null" idea without an AI is > vacuous because we don't really know what this idea entails. OK, but you are doing the vacuuous thing, so I will continue. The point is that even if the checking is not in the language, it is likely their in peoples environments (for us it would be a built in compiler style check, or a rule in our style checking tool, or both). >>(*) to me, any change that converts legal correctly operating >>programs to erroneous programs is an incompatibility of the >>worst possible kind. > I guess that this can happen whenever we have a change that causes a > predefined exception to be raised in a different scope than it originally > was. I am too lazy to check the "inconsistencies" sections of the AARM, > but I'd be surprised if this were the only instance of such a change in > the Ada 83/Ada 95/Ada 2005 history. I can't remember any other change I felt was this bad > Also, are there implementations where dereferencing the null value in > unchecked code would do something other than dumping a core? To me, a > core dump is nearly as good as an exception for the purposes of debugging. My goodness, there is a blind spot there :-) On many targets, dereferencing zero yields zero. **************************************************************** From: Erhard Ploedereder Sent: Thursday, February 16, 2006 12:10 PM there is a small distinction between "exists" and "for all". You said that "confirming rep clauses are really just a case of comments for documentation as well." That still is plain wrong, even if you have one example, where indeed it is. (And frankly, that particular example reminds me of the style guide line to comment each line, resulting in X := X + 1; -- increment X by 1 code.) And hence it does not compare to the "with null" case, as you claimed in support of your argument in favor of "with null". That was my point, nothing more. > It's not a symmetry argument. You can reject the argument, but > at least make sure you understand it! :-) I believe I do understand your proposal. But, it did start out largely as a symmetry argument. Read the Canadian comment, not Robert Dewar's opinion of the subject. And at this stage, it's the Candadians that count. No mention was made of upward compatibility arguments. Until one Robert Dewar usurped the discussion to bend it in that direction. It was a useful discussion, no doubt, but let us not rewrite history. Now, as to your proposal, as soon as you appeal to tools outside the compiler, you're entering an entirely slippery slope. The obvious counter-argument of course is to put in special comments for your special tool, but please don't load the language with unneeded complexity. Especially, when you can provide a cheaper tool to once and forall change "access T" to "access T not null" in all the right places and be done with it, especially since you got the ACATS permission to make the "not null" legal in Ada95. And complexity it is, because lots of people will search the manual for the elusive difference between access T with null; and access T; But, of course, you are not really appealing to a separate tool. We can heap still a little more complexity onto the language, by creating a pragma that controls the need to put "with null" or "not null" in place at all times. And, behold, the compiler now is the external tool. And finally we have reintroduced the feature that I believe was discussed and rejected when the ARG dealt with "not null". Only this time it is a GNAT-defined pragma rather than a language-defined one. (Now I can be accused of rewriting history, too.) **************************************************************** From: Robert Dewar Sent: Thursday, February 16, 2006 12:22 PM > there is a small distinction between "exists" and "for all". You said > that "confirming rep clauses are really just a case of comments for > documentation as well." That still is plain wrong, even if you have > one example, where indeed it is. (And frankly, that particular example > reminds me of the style guide line to comment each line, resulting in > X := X + 1; -- increment X by 1 > code.) Sorry, I just assumed you would realize that obviously not all confirming rep clauses are in this category. As for the enum case, lots of people find this a good idea, it is indeed essentially a comment, but it is an essential one if you are interfacing with the outside world, and much better than a comment, since it is checked by the compiler (if you add an element without fixing the rep clause you will get an error, but not if it were a comment). > > And hence it does not compare to the "with null" case, as you claimed > in support of your argument in favor of "with null". > That was my point, nothing more. Seems comparable to me > I believe I do understand your proposal. > > But, it did start out largely as a symmetry argument. Read the Canadian > comment, not Robert Dewar's opinion of the subject. And at this stage, > it's the Candadians that count. We are talking about a new feature, I don't think there is some rule that only the original proposers view of its advantages are allowed to be argued! > No mention was made of upward compatibility arguments. Until one Robert > Dewar usurped the discussion to bend it in that direction. It was > a useful discussion, no doubt, but let us not rewrite history. It is not a matter of rewriting history, but merely explaining why I think the Canadian proposal is a good idea. > > Now, as to your proposal, as soon as you appeal to tools outside the > compiler, you're entering an entirely slippery slope. The obvious > counter-argument of course is to put in special comments for your special > tool, but please don't load the language with unneeded complexity. > Especially, when you can provide a cheaper tool to once and forall change > "access T" to "access T not null" in all the right places and be done with > it, especially since you got the ACATS permission to make the "not null" > legal in Ada95. The cheaper tool does NOT help, please reread carefully. People are not doing a once-and-for-all change, they do not make a sudden transition from Ada 95 to Ada 2005, and for sure they do not want to jump off a cliff. > And complexity it is, because lots of people will search the manual for > the elusive difference between > access T with null; > and > access T; > > But, of course, you are not really appealing to a separate tool. We can > heap still a little more complexity onto the language, by creating a pragma > that controls the need to put "with null" or "not null" in place at all > times. And, behold, the compiler now is the external tool. And finally we > have reintroduced the feature that I believe was discussed and rejected when > the ARG dealt with "not null". Only this time it is a GNAT-defined pragma > rather than a language-defined one. > (Now I can be accused of rewriting history, too.) Well the ARG also rejected allowing NOT NULL in Ada 95, but now seems inclined to change its mind. As I said earlier, that's at least a step in the right direction. But it does not solve the backwards forwards compatibility, which WITH NULL + a tool does. I agree a stylized comment could be used instead, but surely you don't think that's preferable from a language point of view. **************************************************************** From: Jean-Pierre Rosen Sent: Thursday, February 16, 2006 12:39 PM > yesyesyes, you are missing the kind of case I am talking > about, sorry I thought it was obvious. Cases are > > type X is range - 2**31 .. + 2**31-1; > for X'Size use 32; This one can be confirming on one implementation, and not on another one. It is therefore definitely useful! **************************************************************** From: Robert A. Duff Sent: Thursday, February 16, 2006 12:42 PM > yesyesyes, you are missing the kind of case I am talking > about, sorry I thought it was obvious. Cases are > > type X is range - 2**31 .. + 2**31-1; > for X'Size use 32; I think that's checked in the sense that Pascal is talking about. If you accidentally wrote: type X is range - 2**31 .. + 2**31; -- forgot "-1" for X'Size use 32; you will get an error, because X'Size = 33. Even with the example as you wrote it, you'll get an error on a ones complement machine. ;-) > type M is (X, Y); > for M use (0, 1); OK, no real checking here... Note that this was not necessarily confirming in Ada 83, and I think the reason it's so common is that people wanted to make sure the compiler did what all compilers do. In any case, I think we agree that "with null" is useless if it's not checked. Hence my assumption that there will be a pragma or some other way to enforce some useful rules. I don't care too much whether that pragma is language defined or implementation defined. We still need to nail down what the pragma would do. I think there are several choices, and the devil's in the details as usual. Pascal and Randy suggested I write up an AI on "with null", and I will do so someday, if I find some spare time. But I'm in no hurry, because I'm opposed to putting "with null" in the upcoming Ada 2005 standard, because it would slow down the process. Such an AI should at least propose rules for the pragma, if not propose to add the pragma to the language. **************************************************************** From: Robert Dewar Sent: Thursday, February 16, 2006 5:25 PM >> type X is range - 2**31 .. + 2**31-1; >> for X'Size use 32; > > This one can be confirming on one implementation, and not on another > one. It is therefore definitely useful! > Oops, sorry, typo, this is NEVER confirming, the confirming declaration is of course for X'Size use 31; (a size of 31 is mandated for this type) **************************************************************** From: Robert Dewar Sent: Thursday, February 16, 2006 5:32 PM > I think that's checked in the sense that Pascal is talking about. > If you accidentally wrote: > > type X is range - 2**31 .. + 2**31; -- forgot "-1" > for X'Size use 32; > > you will get an error, because X'Size = 33. chuckle, you followed my typo, you mean 31 and 32 :-) > Even with the example as you wrote it, you'll get an error on a ones > complement machine. ;-) Yes, and what about a threes complement machine. There are just as many threes complement machines in the world as 1's complement :-) well if you really want an example that is truly independent type M is (X, Y) for M'Size use 1; (quite a common diction actually) > In any case, I think we agree that "with null" is useless if it's not > checked. Hence my assumption that there will be a pragma or some other way to > enforce some useful rules. I don't care too much whether that pragma is > language defined or implementation defined. We do *NOT* agree on this at all, for two reasons. 1) it is perfectly useful to have coding standards which are not checked by tools. You don't need a policeman there to make you behave :-) 2) completely different point. It is useful to be able to write an Ada 2005 program which works only in Ada 2005, which will not compile if you try it on an Ada 95 compiler. By following the rule of using WITH NULL always, you make sure that your Ada 2005 program which will not run properly on Ada 95 will be rejected by an Ada 95 compiler. Without the change, you end up with a program that is legal in Ada 95 and Ada 2005, and there is no indication in the program text that this is an Ada 2005 program only. **************************************************************** From: Pascal Leroy Sent: Friday, February 17, 2006 3:14 AM > >> type X is range - 2**31 .. + 2**31-1; > >> for X'Size use 32; > > Oops, sorry, typo, this is NEVER confirming, the confirming > declaration is of course > > for X'Size use 31; > > (a size of 31 is mandated for this type) Wow! If you manage to squeeze this type on 31 bits, you must use an impressive compression algorithm. Is it related to US patent 5,533,051? (Details at http://gailly.net/05533051.html.) **************************************************************** From: Robert Dewar Sent: Friday, February 17, 2006 1:34 PM Can't believe it, well I certainly don't want to treat on any patent, especially one as impressive as this, so I withdraw my implicit suggestion that we incorporate this patent into the design of Ada 2015 (I think it would be too late for 2005 anyway) :-) :-) **************************************************************** From: Pascal Leroy Sent: Friday, February 17, 2006 2:54 AM > > type M is (X, Y); > > for M use (0, 1); > > OK, no real checking here... That's what was claimed by one instance of Robert Dewar, but another instance of Robert Dewar cleverly pointed out that it's not true. If, during maintenance, you add a new enumeration literal to type M, the compiler is going to draw your attention to the enumeration representation clause. This is especially important if the new literal is not added at the end of the type: in the absence of a clause, the representations would just shift silently. Confirming representation clauses are very useful for maintenance: in many cases the compiler will flag those changes to the type that may affect the representation **************************************************************** From: Robert Dewar Sent: Friday, February 17, 2006 5:17 AM > Confirming representation clauses are very useful for maintenance: in many > cases the compiler will flag those changes to the type that may affect the > representation Indeed. I actually think that there should be a rule that the compiled accept all confirming representation clauses, which is not necessarily the case. However, with only the attributes in the RM, you actually cannot write a full set of confirming rep clauses anyway (because you cannot control size of subtypes, or object sizes -- that's why we added the attributes Object_Size and Value_Size to GNAT). **************************************************************** From: Robert Dewar Sent: Friday, February 17, 2006 5:21 AM > That's what was claimed by one instance of Robert Dewar, but another > instance of Robert Dewar cleverly pointed out that it's not true. Actually, the two Dewar's are consistent here. On the one hand, the rep clause serves no purpose, since it is just a comment, but in a maintenance context it is useful. That's actually my analogy with WITH NULL. On its own in an Ada 2005 program, it serves no purpose other than documentation, but in a maintenance context it certainly does get checked if you try to compile in Ada 95 mode, and it might get checked bya pragma or tool. Just to be clear, I don't see adding WITH NULL at this late stage given no clear support. I would like to see allowing NOT NULL in Ada 95 (in fact we just made this change -- again -- in GNAT) and we will cough up some NOT-NULL'ing tool, and perhaps a style check requiring the use of NOT NULL in Ada 95 mode. P.S. regarding pragmas that enforce style checking type stuff, I was surprised to see that the pragma for overriding had disappeared, so I assumed that the ARG had somewhat decided that such pragmas did not belong in the official language anyway. **************************************************************** From: Pascal Leroy Sent: Friday, February 17, 2006 6:34 AM > Indeed. I actually think that there should be a rule that the > compiled accept all confirming representation clauses, which > is not necessarily the case. There is actually an IA to that effect in Ada 2005, see 13.1(21.1). Of course, with dope and dynamic stuff and so on this cannot be a requirement. But this IA is intended to nudge implementers in the right direction. [This thread became AI05-0009-1, and the mail continues there. - Editor] From: Randy Brukardt Sent: Friday, February 17, 2006 2:36 PM > But I envision using a coding convention that requires "with null" in certain > well-defined cases. And some way to automatically enforce that convention, > such as a pragma. If we could turn back the clock, I'd then make "not null" > be the default, and eliminate the "not null" syntax. I miss a day due to a snowstorm, and people lose their minds. :-) I can't begin to imagine why you would think making "not null" the default would be a good idea. (It was a lousy idea in Ada 95, and it still is.) -- Ada doesn't allow widening of types, so the least restrictive type needs to be the root (and default); -- We surely don't want the semantics of parameters and named types to differ; -- "not null" is inappropriate for most general uses; usually, you need an indication of "no object" -- the default should be the most common use -- even for parameters, the need to be able to pass "no object" is common (see interfacing to C, for one example). I can see some value to the "with null" proposal, presuming it adds some compile-time checking. But I don't see any point in adding something solely for the benefit of external tools. In any case, if you think this is important, write up an AI so we have something specific to discuss. As it is, there seems to be as many ideas of what this should mean as there are ARG members, and we're wasting a lot of time because of it. **************************************************************** From: Robert Dewar Sent: Friday, February 17, 2006 2:41 PM > I can't begin to imagine why you would think making "not null" the default > would be a good idea. (It was a lousy idea in Ada 95, and it still is.) Perhaps because he has *not* lost his mind and still remembers that upwards compatibility is a NUMBER ONE priority in designing new features. You simply do not have the luxury of fixing things at this expense. > -- Ada doesn't allow widening of types, so the least restrictive type needs > to be the root (and default); I don't see that argument > -- We surely don't want the semantics of parameters and named types to > differ; why not? they were different in Ada 95, maybe it was a mistake, but it is a mistake we should live with. > I can see some value to the "with null" proposal, presuming it adds some > compile-time checking. But I don't see any point in adding something solely > for the benefit of external tools. er hum! Hate to repeat myself, but unless you think of the Ada compiler as an external tool, then this is NOT just for the benefit of Ada tools. An important part of WITH NULL is that it allows you to write a program that assumes Ada 2005 semantics in a manner that will cause it (like many other Ada 2005 extensions) to be rejected by an Ada 95 compiler. **************************************************************** From: Randy Brukardt Sent: Friday, February 17, 2006 3:37 PM ... > Perhaps because he has *not* lost his mind and still remembers that > upwards compatibility is a NUMBER ONE priority in designing new features. > > You simply do not have the luxury of fixing things at this expense. Let me remind you that we originally designed a change that had exactly this property. But the Ada users who reviewed the proposal found it distasteful, and felt that the incompatibility was better than the alternatives. We decided to follow the users in this case. I can only recall one other instance where we changed a proposal because of strong user comments - it's not something that we've done lightly. It's of course interesting that the strongest user voices were at AdaCore. Now, with additional experience/information/whatever, we might make another decision. In any case, the WG 9 instructions were quite clear that compatibility, while a high priority, is not the only such consideration. Making/keeping the language consistent, for instance, also enters into the equation. I think we were pretty conservative about accepting incompatibilities. You can disagree with the WG 9 instructions, but it's a little late (about 5 years) to be complaining about that. **************************************************************** From: Robert Dewar Sent: Friday, February 17, 2006 3:55 PM > But the Ada users who reviewed the proposal found it distasteful, and felt > that the incompatibility was better than the alternatives. We decided to > follow the users in this case. I can only recall one other instance where we > changed a proposal because of strong user comments - it's not something that > we've done lightly. Harumph! What's the ARG methodology for choosing representative users to review proposals? I suspect there is none, and that you are really reacting to an online community of enthusiasts, who do not represent real Afda users. > > It's of course interesting that the strongest user voices were at AdaCore singular please, one person, and I assure you we have NO users at AdaCore, only enthusiasts. Franco would be the first to say that he is not representative of the Ada user community, except by proxy. Of course that's the same status that ARG users have. I agree that input from real users would be a great idea. > Now, with additional experience/information/whatever, we might make another > decision. > > In any case, the WG 9 instructions were quite clear that compatibility, > while a high priority, is not the only such consideration. Making/keeping > the language consistent, for instance, also enters into the equation. I > think we were pretty conservative about accepting incompatibilities. You can > disagree with the WG 9 instructions, but it's a little late (about 5 years) > to be complaining about that. Making the language consistent is important, but it's secondary. After all we managed to live with an inconsistency here for ten years without any significant complaints. Yes, people did complain about the NOT NULL semantics of access parameters (as well they might, it was a clear design error in my view). But I never heard users complaining about the inconsistency. Now of course, we have introduced anonymous access types into Ada 2005, and yes, it is important that they be consistent with parameters, but I see no compelling argument for consistency at any other level. The right thing to do would have been to assume NOT NULL by default in both cases for compatibility with Ada 95, and allow WITH NULL to specify that null was allowed. But please note that my position at this stage is that as long as we allow NOT NULL in Ada 95, we are not in too terrible a position. The thing that really upset me was removing this useful decision. At least it seems we may get that back as a result of this discussion, which means that the Canadian proposal, while it has not got enough support to fix the problem, has at least resulted in alleviating the problem. **************************************************************** From: Tucker Taft Sent: Friday, February 17, 2006 4:06 PM > ... > The right thing to do would have been to assume NOT NULL by default in > both cases for compatibility with Ada 95, and allow WITH NULL to specify > that null was allowed. Robert, you do have a way of making pronouncements! ;-) We certainly debated this long and hard in the ARG, and we did our best to consider both existing and future users of Ada 2005. We came to a different conclusion, and personally, I believe it was the right thing for the language. Your mileage may vary... **************************************************************** From: Robert Dewar Sent: Friday, February 17, 2006 5:42 PM Well I call things as I see them :-) In this case I think it would have been a good idea to get some systematic input from real users. Well hopefully in practice I am too worried about the problem, and no one will notice the incompatibility! I guess I just take upwards compatibility as a much more important and absolute requirement. For sure this will make it harder to sell Ada 2005, though the ability to use NOT NULL in Ada 95 will in practice help a lot, and probably be sufficient to deal with the problem. **************************************************************** From: Robert A. Eachus Sent: Saturday, February 18, 2006 9:05 PM Amen. I just talked to someone about a ride to church tomorrow, and explained that I sounded frustrated, by this discussion. I said something like: "All of the proposed fixes will be studied. Eventually the ARG will stop playing WG9 level politics and recommend the right technical fix..." I think we have to stop playing at being WG9, and do the job of the ARG. To sum up huge numbers of posts: Is there something here that is broken? Well, er, sort of, maybe, yeah, but not too badly. Should it be fixed? Not if it delays the new standard. I didn't ask you that. Should it be fixed? Maybe. How should it be fixed? Well, er, uh. Let me get back to you on that. Robert Dewar's point, that allowing the *non null *notation in Ada 95 reduces the severity of the issue is the sort of thing that belongs in an ARG discussion. But the major issue in this discussion seems to be whether the issue is important enough to hold up the standard. That is an important question to answer, and we should be giving WG9 what advice we can about that. But WG9 should be the ones making the final decision--even when it is the same people. As I see it there are several positions the ARG can take on the Canadian proposal: 1) There is no serious problem with the current draft standard. The Canadian proposal is a nice to have, but way too late. (Note that in this situation, and only if there is no serious issue, does the ARG opinion on timeliness matter.) 2) There is a problem, and here is our best technical proposal for fixing it. If the problem is serious, then a rejection or even yes with comments votes at the WG9, SC22, or JTC1 level could delay things much more than taking the time to find the right fix now. (IMHO, the Canadian proposal identifies a problem, but certainly their proposed repair needs a lot of detailed work. That is the ARG's job, though.) 3) There is a problem, but it is minor and we suggest fixing it either in the next version of the standard or a Corrigendum. I think choice 3) is right out. The problem identified is most serious in Ada 95 to Ada 2005 migration. Even if it wasn't, a second incompatable change would be right out, so we had better get it right right now. I have become convinced that the first possibility is also out. Do I think that allowing non null in Ada 95 is a complete solution? No, it might be enough of an answer to allow us to move forward, but there is another issue I see. The problem that I now see is that a lot of ARG members have this magic concept of annonymous access types. What is the magic? That the base type of such access types does not include null. In Ada 95 as I see it, this was not a big issue. If you squinted just right, annonymous access types were separate from named access types, so there was no issue. But as I see it, in Ada 2005, this viewpoint doesn't work. You can convert from a named access type to an anonymous access type. A necessary and useful feature. But we now run into the issue that Tucker accidently identified with his 'Base proposal: Compilers are expected to translate from named types to anonymous access parameters with low or no overhead, in practice most base types will actually be the same. But converting from a null-including subtype to a null-excluding subtype will imply a check. So far, so good. But what happens when that check is suppressed? Robert Dewar's post about compiling the Ada Core run-time suddenly started ringing alarm bells, especially when put together with the discussion of 'confirming' rep clauses. Much as I would like to say otherwise, I think that if you use an explicit *non null *subtype for passing parameters, that had better be checked--even if this implicitly overrides pragma Suppress. Now, *with null *Foo, or Tucker's Foo'Base has real semantics, including the reverse check in function returns and *in out* parameters. Is it necessary semantics to support in Ada 2005? I don't know. I do know that it will be extremely useful when writing thin bindings to libraries or operating systems in C. This may be why I was the only one who seemed to think that Foo'Base possibly had more values than the first named subtype in "*type* Foo *is non null access* Bar;" Certainly we all know that the arithmetic operators are now written in the RM with 'Base to make it clear that they do not check the subtypes on call or return. I thought everyone here realized that Foo above is a subtype of an anonymous type, and Foo'Base, if added to the language would allow users to name that type. It is not a subtype with more values than it's parent type, just the name of the parent type. In any case, I think we do need to deal with the real issue here, which is not the syntax--I can live with *with null*, *accept null*, or 'Base. The real question is whether we need to allow programmers to specify what they expect? I think we do, in fact, from some of the discussion here, it is clear that if we don't get it right, we can't expect compiler writers--most of whom are represented here to figure out where to put the checks for null, and when it is okay to omit them. **************************************************************** From: Robert A. Duff Sent: Tuesday, July 18, 2006 3:22 PM AI-447 says: > !wording > > Replace 3.10(6) by: > > access_definition ::= access [not null] subtype_mark But it should be "[not null] access subtype_mark". **************************************************************** From: Randy Brukardt Sent: Tuesday, July 18, 2006 3:30 PM Yes, of course, that's in the meeting minutes I passed out. You really need to come to meetings.... Also, the AI on the Internet (version /02) has that fixed (since June 16th). ****************************************************************