CVS difference for ai12s/ai12-0003-1.txt

Differences between 1.8 and version 1.9
Log of other versions for file ai12s/ai12-0003-1.txt

--- ai12s/ai12-0003-1.txt	2014/07/10 00:16:12	1.8
+++ ai12s/ai12-0003-1.txt	2015/01/22 02:41:26	1.9
@@ -912,3 +912,92 @@
 vastly preferable, anyway.
 
 ****************************************************************
+
+From: Brad Moore
+Sent: Saturday, January 17, 2015  1:29 PM
+
+I'm looking at my homework relating to specifying the default storage pool,
+and have a question.
+
+At the last ARG meeting, Tucker provided some guidance and suggested that it
+be illegal if (without any context) (Standard) denotes anything other than
+package Standard."
+
+This is to deal with the situation where someone specifies the default storage
+pool as "Standard" which is an identifier specific to the pragma, when there
+is another declaration that is directly visible having the same name.
+
+My original approach would be to disallow any such name conflict, but I think
+that may be too draconian.
+
+eg.
+
+    type Foo is interface;
+    function Standard (Item : Foo) return Integer;
+
+    pragma Default_Storage_Pool (Standard);  -- Legal?
+    type Foo_Access is access Foo;
+
+I think it's clear here that the Standard in the pragma is not referring to
+the Standard function.
+
+I'm thinking that it would be better to define legality such that only
+conflicts with other directly visible storage pool declaration names are
+disallowed.
+
+Specifically, it would be illegal to specify the Default_Storage_Pool pragma
+as Standard, if there is a directly visible storage pool declaration with the
+name "Standard".
+
+Alternatively, we could simply disallow declaring storage pools that have the
+name "Standard", but that would introduce a minor backwards incompatibility.
+It seems pretty minor and quite unlikely to occur in practice, but perhaps
+such an incompatibility should be eliminated if there is another solution
+such as what I initially proposed, that doesnt have this incompatibility.
+
+Thoughts?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, January 17, 2015  6:28 PM
+
+I think this is a non-problem. I'd be happy with no check at all, but if we
+have to have one, I think it should be as simple as possible.
+
+That's mainly because "Standard" is one of those identifiers in Ada that
+aren't reserved, but should be treated as if they are. You don't want to be
+declaring things named "Standard" anymore than you want to declare things
+named "Integer" or "Character". You *can* do that, but it's an invitation to
+confusion.
+
+So I don't really care if the check picks up things that aren't really going
+to be confused. Because they're not likely to exist anyway.
+
+Indeed, I'd probably implement this check as "if there is more than one
+definition of Standard in the current symboltable, reject the pragma". That
+is, I wouldn't pay any attention to visibility or what's being declared.
+Most likely, that would pick up a few cases that aren't a problem, but (A)
+there probably isn't going to be an ACATS test that could tell the difference;
+and (B) this will never happen in practice.
+
+In the amazingly unlikely event that that simple check causes a problem for
+someone, I'd upgrade it to using identifier lookup (which does use visibility);
+then "if there is more than one visible Standard, reject the pragma". This is
+still rather simple, as no resolution is needed.
+
+Your check would require bringing the entire machinery of resolution into the
+picture (after all, "Standard" could be an object, but it also could be a
+parameterless function call). That seems like swatting a fly with a bazooka.
+
+To summarize, I'd prefer to stick with the original idea -- the simpler the
+check, the better.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, January 18, 2015 11:10 AM
+
+OK, will do.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent