Re: Top 10 Worst C# Features

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 5 Sep 2015 09:45:43 +0300, Niklas Holsti wrote:

> - Outputs of a computation can be made available to a caller, without 
> the caller having to declare "out" variables, by implementing the 
> computation in the elaboration block in the body of a generic package, 
> which has generic formal objects corresponding to the formal "in" and 
> "in out" parameters of the computation, and declares public variables 
> corresponding to the "out" parameters of the computation. To "call" this 
> computation, the "caller" instantiates the generic, and can then access 
> the public variables of the instance, with the values computed at 
> elaboration of the instance, without explicitly declaring her own 
> variables for use as "outs". But I'm sure that most programmers would 
> consider this to be a weird misuse of the generic facility. Further, the 
> instantiation must be done as a declaration, not as a statement, and the 
> "out" variables can seldom be declared constant, because the computation 
> is often too complex to be done in the declaration of the generic package.

It is worth to have a language construct for this. There are cases beyond
multiple out parameters when this is necessary, e.g.

   if X in T'Class then
      declare
          Y : T'Class renames T'Class (X);

or

   if Ptr /= null then
      declare
          X : T := Ptr.all;

> In a more functional-programming approach, a procedure could be made to 
> "return" its outputs by calling different "continuation" procedures 
> (given as "in" parameters) for the different outcomes; each such 
> continuation procedure could have its own set of "in" parameters 
> corresponding to the "outs" available from the original procedure in 
> this outcome. This would be rather far from the procedural Ada style, 
> but perhaps it could be used as the internal implementation of what I 
> proposed above, even if the source syntax does not look like continuations.

This is an independent case to me. It falls into the basket "co-routines".
If we had co-routines we could use them to handle multiple outputs.

BTW, this is rather data-driven approach than functional. DDA is a mess on
a much bigger scale than one could imagine...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de