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

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0304-1.txt

--- ai12s/ai12-0304-1.txt	2019/01/11 08:23:06	1.1
+++ ai12s/ai12-0304-1.txt	2019/01/13 06:32:23	1.2
@@ -366,3 +366,110 @@
 possible I missed something.)
 
 ****************************************************************
+
+From: Steve Baird
+Sent: Friday, January 11, 2019  5:39 PM
+
+> I think it might be a good idea to make a list of every 
+> language-defined type. Trying to remember them from memory is bound to miss some.
+
+In particular, we might want this AI to say something about images for 
+System.Address (at least in the case where the implementation advice 
+suggesting that System.Address should be declared as a private type is 
+followed) and for Ada.Tags.Tag.
+
+>>      For each language-defined container type T (i.e., each of the 
+>> Vector,
+...
+> More important: Personally, I would prefer this is an Implementation 
+> Requirement. If we think it is important to specify the Image for an 
+> array (and we did), we ought to give the same treatment to the 
+> containers. After all, a Vector is as close as we can make it to an 
+> array with a sticky lower bound. You've specified to about the same 
+> level as we specified the array and record aggregates, so it should be fine 
+> as a requirement.
+
+Makes sense. The key point is, as you point out, to treat container types 
+consistently with concrete composite types.
+
+>>      AARM Note:
+>>      For each language-defined private type T, implementations are
+>>      encouraged to ensure that T'Image generates images that would be
+>>      meaningful based only on the relevant public interfaces, as opposed
+>>      to requiring knowledge of the implementation of the private type.
+> 
+> *This* seems like relevant Implementation Advice.
+
+The other alternative I was considering (as opposed to an AARM note) was to 
+say nothing at all on the grounds that this should just be common sense. 
+Making it implementation advice seems more like an attempt to legislate 
+good taste.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 11, 2019  6:17 PM
+
+> > I think it might be a good idea to make a list of every 
+> > language-defined type. Trying to remember them from memory
+> > is bound to miss some.
+> 
+> In particular, we might want this AI to say something about images for 
+> System.Address (at least in the case where the implementation advice 
+> suggesting that System.Address should be declared as a private type is 
+> followed) and for Ada.Tags.Tag.
+
+I would say that type Imaginary (since it is supposed to be numeric) also 
+qualifies.
+
+Bounded_String and Unbounded_String also seem important (in that they're 
+heavily used), but maybe not as much since there are other ways to get an 
+string value from them.
+ 
+...
+> >>      AARM Note:
+> >>      For each language-defined private type T, implementations are
+> >>      encouraged to ensure that T'Image generates images that would be
+> >>      meaningful based only on the relevant public interfaces, as opposed
+> >>      to requiring knowledge of the implementation of the private type.
+> > 
+> > *This* seems like relevant Implementation Advice.
+> 
+> The other alternative I was considering (as opposed to an AARM note) 
+> was to say nothing at all on the grounds that this should just be 
+> common sense. Making it implementation advice seems more like an 
+> attempt to legislate good taste.
+
+Since when do implementers have common sense or good taste?? :-)
+
+I think this is important enough to at least mention, since I can see (from 
+the implementation prespective) reasons for doing the easiest thing -- which
+is nothing and just letting the default implementation (which would show all 
+of the private components) show through. But this is *not* what we want, nor,
+I suspect, what most users would want. And it's important to tell the Ada user
+that the intent isn't to let random implementation junk show through, thus 
+suggesting IA. Maybe just a Note would be better.
+
+There definitely is value is lightly explaining what we consider good taste.
+They're always welcome to ignore IA, after all (it's never bothered me :-).
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, January 11, 2019  6:49 PM
+
+> Maybe just a Note would be better.
+I said an AARM note or perhaps nothing at all, you said Implementation Advice .
+
+A Note sounds like a good way to split the difference.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, January 11, 2019  9:21 PM
+
+We almost never use Notes directed at implementations.  Notes are almost 
+always for the user.  I would stick with Implementation Advice or an AARM 
+note.  At this point, I suggest we leave the final decision to an ARG meeting.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent