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

--- ai12s/ai12-0240-1.txt	2017/10/10 01:27:59	1.1
+++ ai12s/ai12-0240-1.txt	2017/10/12 03:45:21	1.2
@@ -77,6 +77,23 @@
      governing the initial assignment if any are covered below,
      as are assignments from a later assignment statement.
 
+* Creating values
+   # Legality rule: The attributes Access and Unchecked_Access shall not be
+     used to create a value of an access type with a True Ownership aspect.
+     
+* Converting values
+   # Legality rule:
+     In a type conversion, if the target type is an access type with Ownership
+     aspect having the value True:
+       + The operand type shall also have the Ownership aspect True;
+       + The storage pool of both the operand and target type shall be the
+         standard storage pool, or both shall be non-standard storage pools.
+   # Dynamic semantics:
+     In a type conversion between two types with Ownership aspect True,
+     where both have non-standard storage pools, a check is made that the
+     Storage_Pool attribute of the two types denote the same object. 
+     Program_Error is raised if this check fails. 
+
 * Assignment to an access-to-variable object:
    # Legality rule: The RHS shall be valid, an allocator, or the literal null.
      If not a null literal or an allocator, the RHS shall be local to the
@@ -555,5 +572,108 @@
 
 It might be that this idea is best left as a SPARK feature, since it doesn't
 seem to fit into the existing model of what an Ada compiler is required to do.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, October  9, 2017  8:36 PM
+
+You may not buy the rationale, but in my view, safe storage management is a
+huge issue, and many languages have adopted full garbage collection, not
+because it is a "good thing," but merely because having to deal with storage
+leaks and dangling references is so painful.  
+
+I think if Ada had a "mode" in which all storage management was safe and
+automatic, and there were no dangling references or storage leaks, and yet
+also no asynchronous garbage collector meaning that real-time guarantees are
+straightforward, all in the presence of multitasking and/or parallelism, this
+would be truly extraordinary.  In my experience using a language that has
+these features (ParaSail) improves productivity by another order of magnitude
+over current Ada.
+
+I realize controlled types were supposed to solve all of these problems, but
+they are painful to get right, can make debugging significantly harder, can
+add measurable overhead, and don't really address issues of multi-tasking.
+
+I agree this AI is a lot of work, but I think the payoff could be enormous.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October  9, 2017  9:07 PM
+
+> You may not buy the rationale, but in my view, safe storage management 
+> is a huge issue, and many languages have adopted full garbage 
+> collection, not because it is a "good thing,"
+> but merely because having to deal with storage leaks and dangling 
+> references is so painful.
+
+You didn't give that as a rationale! The only thing the AI talks about is
+roving programs and eliminating aliasing.
+
+I'm surely not against "safe storage management" (that would be like being
+against apple pie!), but I don't see how the features in the AI provide
+anything safe. (Quite the reverse in fact, unless one assumes things about the
+TBDs known only to the author.) 
+ 
+> I think if Ada had a "mode" in which all storage management was safe 
+> and automatic, and there were no dangling references or storage leaks, 
+> and yet also no asynchronous garbage collector meaning that real-time 
+> guarantees are straightforward, all in the presence of multitasking 
+> and/or parallelism, this would be truly extraordinary.
+
+Yes, it would be truly extraordinary. I'd actually say impossible. :-)
+
+If you can do that, without (a) wrecking the model of Ada (i.e. generic
+contract model), (b) wrecking Ada implementations  (i.e. requiring flow
+analysis were none is previously required), and (c) wrecking portability
+(i.e. requiring checks without sufficient definition), please do so. But the
+proposal you sent does none of that, and doesn't even give a rationale for
+anything that would help a non-SPARK Ada user. As I initially said,
+insufficiently baked.
+
+To get this proposal into anything resembling a usable form by mid-2019 would
+require putting virtually all of our effort into that, and forgetting about
+parallel operations, Global, and most of the other open proposals.
+(That is, the stuff we've already promised.) A proposal would have to be
+absolutely stupendous for that, and you'd have to make a much better case (in
+particular, that you could really deliver the benefits that you claim in this
+e-mail *and* keep usability).
+
+P.S. I'd much rather you did your homework rather than coming up with new
+pie-in-the-sky ideas. I realize the latter is more fun, but fun doesn't get
+anything finished, and we're entering the home stretch of this Standard.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, October  9, 2017  10:18 PM
+
+I realize this isn't part of my homework, but it seems important to at least
+add the conversion rules into this, so it can be evaluated for safety.
+Without the conversion rules, safety is clearly hopeless to evaluate.
+
+So here is an update which adds conversion rules (and disallows 'Access and
+'Unchecked_Access). [This is version /02 of the AI - Editor.]
+
+I promise to do no more work on this until all my other homework is done... ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, October 11, 2017  10:42 PM
+
+(A) This has been assigned AI12-0240-1.
+(B) The AI had horrible formatting, which I fixed. But that prevents comparing
+    for changes, so I just copied the "Converting values" part and left the
+    rest alone. Since you left the TBD about conversions later in the
+    description, I'm pretty sure you didn't do a careful update. Hope I
+    didn't miss any other change.
+(C) Ada has a name for an access type doesn't allow 'Access and
+    'Unchecked_Access -- a pool-specific type. An anonymous type can't specify
+    an aspect anyway, so those can't be involved. So why not just say that the
+    types in question have to be pool-specific? It seems simpler and fewer
+    rules would be needed (the needed conversion rules already exist for those
+    types).
 
 ****************************************************************