!standard  13.9(3)                                    01-10-16  AC95-00015/01
!class uninteresting 01-10-16
!status received 01-10-10
!subject Unchecked attribute

!summary

!appendix

From: V. Santhanam (Boeing)
Sent: Wednesday, October 10, 2001 8:42 AM

Issue:

Ada supports unchecked_conversion between types which are not normally
convertible to and from. To achieve this one must WITH the generic function
unchecked_conversion and instantiate it for the target-destination type
pair. The instantiated function can then be used as any other function to
achieve the conversion. All of this just to request the compiler to treat an
expression of one type as if it were an expression of another type.
Typically, the compiler generates no code for any of the constructs used to
achieve this permission.

Solution:

Introduce a predefined attribute Unchecked. The syntax for its use will be:
	type_name'Unchecked (expression)
The static semantics of the construct are that the compiler treats
expression as if it were an expression of type type_name. The type of
expression itself must be determinable without an expected type (as in the
case of ordinary type conversions now). An implementation may place the
restriction that the size of the type of expression be the same as the
type_name'Size.

Reasoning:

It has been argued that the current arrangement is deliberate in that it
should not be easy to use this unsafe feature. I believe making a feature
hard to use is neither healthy nor effective. The fact that this feature has
been in the language from day one suggests that it is well understood by the
programming community that the feature is direly needed in some
applications. Having recognized this need, it is silly to argue that we are
going to make it HARD to use. What is needed is that such uses should be
self-evident in every context. However, the present scheme does not provide
this. For example, it is not uncommon to instantiate Unchecked_Conversion in
a project-wide package and use it wherever needed. And if the name of the
instantiation is not carefully chosen, the uses of the unsafe function can
be obscure. For example,

	function To_Integer_32 is new Unchecked_Conversion (Unsigned_32,
Integer_32);

does not make it evident in a use like:

	Y := My_Types.To_Integer_32 (X);

that there is unchecked conversion going on here. The proposed scheme will
make it evident at the site:
	Y := Integer_32'Unchecked (X);

****************************************************************

From: Christoph Grein
Sent: Friday, October 12, 2001 12:19 AM

> Having recognized this need, it is silly to argue that we are
> going to make it HARD to use.

No, it's not made _hard_ but _obvious_ at the top via a with-clause.
Your attribute is hidden in the executable part and thus not obvious.

> What is needed is that such uses should be
> self-evident in every context. However, the present scheme does not provide
> this. For example, it is not uncommon to instantiate Unchecked_Conversion in
> a project-wide package and use it wherever needed. And if the name of the
> instantiation is not carefully chosen, the uses of the unsafe function can
> be obscure. For example,
>
> 	function To_Integer_32 is new Unchecked_Conversion (Unsigned_32,
> Integer_32);

Then this is a naming problem. They should have chosen a name like
Unchecked_integer_32.

> does not make it evident in a use like:
>
> 	Y := My_Types.To_Integer_32 (X);
>
> that there is unchecked conversion going on here. The proposed scheme will
> make it evident at the site:
> 	Y := Integer_32'Unchecked (X);

Again, this is evident only at the place of use, not at the top of the unit
via a with-clause.

****************************************************************

From: Robert Dewar
Sent: Saturday, October 13, 2001  9:49 AM

This attribute can be added perfectly legally by any Ada vendor. The first
step here is to persuade at least one vendor to implement this attribute.
It would be foolish, even there were agreement, for the ARG to mandate a
new attribute that none of the Ada vendors considered worth while
implementing (the implementation of this attribute is certainly trivail
in GNAT, but we do not consider it a desirable addition to the language,
and certainly none of our users have suggested this attribute (and they
are very free in suggesting useful new attributes and pragmas :-)))

****************************************************************

From: Randy Brukardt
Sent: Tuesday, October 16, 2001  7:03 PM

> What is needed is that such uses should be self-evident in every context.

I don't agree with this premise.

> For example, it is not uncommon to instantiate Unchecked_Conversion in
> a project-wide package and use it wherever needed. And if the name of the
> instantiation is not carefully chosen, the uses of the unsafe function can
> be obscure. For example,
>
>   function To_Integer_32 is new Unchecked_Conversion (Unsigned_32, Integer_32);
>
> does not make it evident in a use like:
>
>   Y := My_Types.To_Integer_32 (X);
>
> that there is unchecked conversion going on here.

That's true, and it's irrelevant. With a proper type system, the only thing
needed at the call site is an indication of the conversion. The actual kind of
conversion used to implement this should not matter, be it a type conversion,
an unchecked conversion, or a function call doing a complex calculation.

For example, Claw has defines various types to match the Win32 API. For
example:

    type HWnd is mod 32; -- A window handle.
    type Int is range -2**31 .. 2**31-1;

Sometimes we have to convert between them because of harebrained M$oft API
definitions. Claw is full of

    function To_HWnd is new Unchecked_Conversion (HWnd, Int);

declarations. Clearly, this is the only way to get from an Int to an HWnd. The
exact mechanism for the conversion is generally not interesting (this is just
another abstraction). If there is a problem with Ada, it is that we cannot
"delete" the (normal, checked) type conversion from HWnd to Int, since it will
not do the correct thing (and it usually will work, causing problems on fielded
systems. We had precisely this happen to us with Claw, as Windows NT liked to
declare handles with the upper bit set). [In general, we can't delete
operations in Ada, because doing so causes problems with the generic contract
model.]

****************************************************************