Re: Ada 2012 : aliased parameters ?

[Florian Weimer <fw@deneb.enyo.de>]

* Randy Brukardt:

>> This is unfortunate because it means that this cannot be used to make
>> variadic argument list trick safer and less of a hack.
>
> One could argue that variadic arguments are themselves a hack. :-)

It would make it possible to call this little gem, PostgreSQL's main
client function for executing SQL statements,

   PGresult *PQexecParams(PGconn *conn,
                          const char *command,
                          int nParams,
                          const Oid *paramTypes,
                          const char * const *paramValues,
                          const int *paramLengths,
                          const int *paramFormats,
                          int resultFormat);

without any allocations and in a type-safe manner (for a predefined
set of types).  For such untyped external interfaces, varidic
subprograms are often handy.

> The advantage of the aliased parameters is that they eliminate the runtime 
> checks by forcing the checks to the call site (where they can be statically 
> made 99% of the time).

I'm wondering if it is necessary that the returned limited record is
controlled, so that a reference counter can be incremented and later
decremented to ensure that the access discriminant does not become
dangling.  That would make the whole thing a bit clumsy to use, and
come with quite a bit of run-time overhead.

> The intent is that it is impossible to create a dangling pointer if no 
> unchecked programming is used. (Unchecked_Deallocation, 'Unchecked_Access, 
> Unchecked_Conversion, Address_to_Access_Conversions, abuse of 
> Unchecked_Unions, etc.) That goes for all access types (not just anonymous 
> ones). The problem, of course, is that it is impractical to do much without 
> using one of those things. (I've only succeeded in using 'Access once in one 
> of my programs; in all other cases I had to use 'Unchecked_Access.)

Anonymous access types seem to help quite a bit.  I use 'Access for
access discriminants, creating proxies, to fake the in-out parameter
mode for functions, and on locally defined callback functions.

> (Personally, I prefer to hide pointers as much as possible, as in
> the container cursors, so that dangling pointer detection becomes
> much more possible, and their creation becomes less likely.)

And implicit deference could make them even safer to use.