Private function w/ Tagged return-type.

Private function w/ Tagged return-type.

[Shark8]

Given the following:

with Ada.Streams;
package example is
    Type Subject is tagged private;
    function Create return Subject;
private
        function Input(
		    Stream : not null access Ada.Streams.Root_Stream_Type'Class)
	return  Subject is (Create);

---- private, moved here, will work.
    
    Type Subject is tagged null record
      with Input => Input;

    function Create return Subject is (null record);
end example;

yields the following error message:
     private function with tagged result must override visible-part function
     move subprogram to the visible part (RM 3.9.3(10))

Yet, the given paragraph says:
   For an abstract type declared in a visible part, an abstract primitive subprogram shall not be declared in the private part, unless it is overriding an abstract subprogram implicitly declared in the visible part. For a tagged type declared in a visible part, a primitive function with a controlling result or a controlling access result shall not be declared in the private part, unless it is overriding a function implicitly declared in the visible part.

Is the error correct? 'Input, 'Output, 'Read & 'Write are implicitly created due to the stream operations/attributes, though arguably they are not functions/subprograms.

I should think that it would be perfectly appropriate to place the declarations of the functions you're assigning to 'Read/'Write/'Input/'Output into the private portion of the package.

Re: Private function w/ Tagged return-type.

[Adam Beneschan]

On Monday, July 29, 2013 1:54:40 PM UTC-7, Shark8 wrote:
> Given the following:
> 
> 
> 
> with Ada.Streams;
> package example is
>     Type Subject is tagged private;
>     function Create return Subject;
> private
>         function Input(
> 		    Stream : not null access Ada.Streams.Root_Stream_Type'Class)
> 	return  Subject is (Create);
> 
> ---- private, moved here, will work.
> 
>     Type Subject is tagged null record
>       with Input => Input;
> 
>     function Create return Subject is (null record);
> end example;
> 
> yields the following error message:
> 
>      private function with tagged result must override visible-part function
>      move subprogram to the visible part (RM 3.9.3(10))
> 
> Yet, the given paragraph says:
> 
>    For an abstract type declared in a visible part, an abstract primitive subprogram shall not be declared in the private part, unless it is overriding an abstract subprogram implicitly declared in the visible part. For a tagged type declared in a visible part, a primitive function with a controlling result or a controlling access result shall not be declared in the private part, unless it is overriding a function implicitly declared in the visible part.
> 
> Is the error correct? 'Input, 'Output, 'Read & 'Write are implicitly created due to the stream operations/attributes, though arguably they are not functions/subprograms.

Well, no matter which way you argue, the T'Input function does not have the name "Input" and will not be overridden by a function named "Input".

You can put your Input function in a nested package to avoid the error, since that will make it non-primitive.

                                 -- Adam

Re: Private function w/ Tagged return-type.

[Adam Beneschan]

On Monday, July 29, 2013 2:20:24 PM UTC-7, I wrote:

> You can put your Input function in a nested package to avoid the error, since that will make it non-primitive.

By the way, now that Ada has aspect clauses, I've toyed with the idea of asking for a Non_Primitive aspect so that you can declare that a subprogram is non-primitive even if the rules in 3.2.3 would make it primitive.  This issue has come up multiple times, where a programmer wants to declare a non-dispatching subprogram (or a subprogram with parameters of two different tagged types declared in the same package) but gets defeated by this rule.  You can get around this by nesting it in a subpackage, but this seems like a kludge that shouldn't be necessary any more if an aspect clause were added.  (Also, I'd ask for Non_Primitive=>True rather than Primitive=>False, even though the latter looks better, because I'm not sure if there's any other case where the *default* value for an aspect could be true.  Also, this is a one-way street; there is no reason I can see to allow a "Primitive=>True" aspect on subprograms that would otherwise be non-primitive by 3.2.3.)

                                 -- Adam