Re: Suggestion: Allow functions returning abstract types in certain situations

[Adam Beneschan <adambeneschan@gmail.com>]

On Wednesday, May 21, 2014 7:52:27 AM UTC-7, Victor Porton wrote:
> I think the standard should allow functions returning abstract types, but we 
> can restrict to call such functions ONLY in parent parts of record 
> extensions or private extensions.

Unless you mean "extension aggregates", I'm not sure what you're referring to.  An extension aggregate is an aggregate where the parent part is specified as an expression and the extension fields follow the "with" keyword.  So are you referring to something like this?

    package Pack1 is
        type T1 is abstract tagged record ... end record;
        function Func (X : Integer) return T1;  -- not currently legal
        ...

    package Pack2 is
        type T2 is new Pack1.T1 with record 
            New_Data : Integer;
            ...

    Rec : T2 := (Pack1.Func(N) with New_Data => 0, ...);

If that isn't what you mean by "parent parts of record extensions or private extensions", please explain what you mean, preferably with some sample code. 

Although at first glance this appeared reasonable to me, I think there's a huge problem: how would you write the *body* of the function?  The function would have to return something.  The language doesn't allow you to declare objects of an abstract type, so Func could not declare a local variable "Result" of type T1 that it could return.  Nor could it return an aggregate, which involves creating a temporary object.  In my view, the language model depends heavily on the assumption that an object can never be created whose tag refers to an abstract type; allowing the rule to *ever* be relaxed could be disastrous.

For extension aggregates, perhaps an alternative would be to allow a *procedure* with an OUT parameter as the parent part of an extension aggregate?  Something like

    package Pack1 is
        type T1 is abstract tagged record ... end record;
        procedure Setup (Obj : out T1; X : Integer);  -- not currently legal

and then

    Rec : T2 := (Pack1.Setup(**THIS**, N) with New_Data => 0, ...);

This wouldn't require creating an object of type T1 at any point.  In effect, the program would create an object Temp of type T2, use T1(Temp) [view conversion] as a parameter to Setup which presumably would initialize some fields declared in T1, then initialize the extension fields.  [Note that T1(Temp) does not create an object whose tag is the tag of T1; the object's run-time type is still T2, but the program is now working with a *view* of that object that only allows the fields declared for T1 to be visible.]  The tricky part would be coming up with a syntax; perhaps the "use" keyword could be given a new job?

    Rec : T2 := (use Pack1.Setup(T2, N) with New_Data => 0, ...);

Here I used "use" to indicate that we're going to use a procedure to help set up the fields, rather than using an expression.  (Or maybe "procedure" instead of "use" would work too?)  As for how to specify the "temporary object" that would be passed as a parameter, I used the type name.  Some details would have to be worked out, such as whether and when Initialize would be called if T2 is controlled, build-in-place semantics, and what happens if there are discriminants involved.

                                 -- Adam