Re: Gnat 2013 is out!

["Randy Brukardt" <randy@rrsoftware.com>]

<Stefan.Lucks@uni-weimar.de> wrote in message 
news:alpine.DEB.2.02.1305311319150.13043@debian...
>On Thu, 30 May 2013, Randy Brukardt wrote:
>> "Adam Beneschan" <adam@irvine.com> wrote in message
>>
>>> I've always wanted some kind of feature in Ada that would allow a
>>> caller to provide a "dummy" for OUT parameters, without having to
>>> declare a new variable.  The compiler would allocate a temporary object
>>> (and a separate one for each use of a "dummy") and then discard it
>>> after the call.  It wouldn't work well when parameter types are
>>> unconstrained array or discriminant records, though.
>>
>> Hmm, that seems like a good idea to me. But what would the syntax be? <>
>> maybe?
>>
>>         My_Proc (Obj1, Obj2, Result => <>);
>>
>
>This has two issues:
>
>   1. This won't work if the type of Result is unconstrained, as, e.g., in
>
>      procedure My_Proc(Obj1, Obj2: String; Result : String);

That's not an issue, that's a feature. I would not expect this to work, 
because the "dummy" needs bounds/discriminants. <> means "default 
initialized", and if that is illegal, it should be illegal here, too. 
(Niklas had a suggested way to allow that, but honestly, I find that 
overkill. This is almost exclusively used to discard scalar results (at 
least in the cases I've encountered the need) and as such, I'd prefer it to 
be as simple as possible.

>   2. This would sometimes break overload resolution -- which procedure
>      should be called by "My_Proc (Obj1, Obj2, Result => <>);" if there
>      happens to be another procedure in scope, such as
>
>      procedure My_Proc(Obj1, Obj2: String; Result : Unbounded_String);

That's ambiguous, of course. (And lousy subprogram design, too, but that's 
another story.) There's nothing new here, you get similar effects with 
class-wide objects, literals, and the like. This would resolve like a kind 
of super-literal. And keep in mind this is a convinient short-hand, not 
something that has to work. You can always declare an explicit dummy object 
if this doesn't work.

>I'd suggest
>
>         My_Proc (Obj1, Obj2, Result => String(1 .. 80));

That's ambiguous with type conversions, especially for discriminated types:
    My_Record(1) vs. My_Integer(1)
This is a "nice-to-have" feature, and making resolution much, much harder is 
not worth it. Additionally, I think it is important that this syntactically 
stands out -- it should not look anything like a normal parameter.

>or in general
>
>         My_Proc (Obj1, Obj2, Result => type Name_of_Type);

That's a bit better, but it doesn't evoke the usage of a dummy parameter at 
all. (And it would be hell on syntax error recovery algorithms.) My original 
message noted that the choice of syntax for this would be critical as to 
whether this would be adopted (because readability is so important to Ada, 
and this is not a critical feature). I toned that down when I thought of 
using <> for the parameter, because it seemed like a sensible choice.

Unless the syntax makes it pretty obvious that this is a dummy, discarded 
parameter, this idea is going nowhere. (And it might very well go nowhere 
even if the syntax is perfect.)

                                       Randy.


                                      Randy.