Re: Refactoring and Ada

[dewar@gnat.com (Robert Dewar)]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<u7ddjt7jko763b@corp.supernews.com>...


OK, if you want my 2cents on the UC issue in more detail
here it is. Yes, of course in general functions have to
be allowed to behave erroneously in this case. Consider
for example the case of a signalling NaN returned on a
machine where you are forced to put FPT results into an
FPT register.

However, UC to me is only defined as a function for the
convenience of the LRM. It is not a real function, and we
would be shocked to find a compiler that actually called
a function body using the standard calling sequence. 
Instead what we expect to see is very specialized intrinsic
code that makes sure that UC is well behaved in this kind
of regard.

To argue detailed semantics of UC assuming it is an ordinary function
is a mistake in my opinion. Indeed one
wonder whether it would not have been better to avoid
modeling UC as a function, and perhaps instead use an
attribute

   Integer'Unchecked_Conversion (X);

to make it quite clear that this is special. I also consider the above
to be quite noisy enough (the with
and instantiations are often a bit TOO much of a good thing).

Hmm! nothing to stop an implementation putting this in and
documenting its semantics as 100% operational (with a note
that you can use this attribute and ignore the ARG :-)