Re: What would you like in Ada202X?

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

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a1l30fFuqaU1@mid.individual.net...
> On 12-05-15 09:30 , Randy Brukardt wrote:
...
>> (I don't think there are many routines
>> that take "out" String parameters, because you can't change the size that
>> way.)
>
> But in general, how would "out" parameters of type Root_String'Class (or 
> SomeType'Class) work? Of course the subprogram can call operations like 
> Set_Char on the parameter to alter its value, but what about a 
> whole-object assignment, Parameter := Value? I guess that must raise 
> Constraint_Error if the new Value does not match the actual Parameter in 
> type or discriminants.

Right, but keep in mind that's how it works for composite types in Ada now. 
(The bounds and discriminants are passed in with the parameter, and usually 
you can't change them.) So we're not losing anything here, especially as the 
current types are arrays, for which you can never change the bounds.

...
> Same sentiments here (I assume by "limited cases" you don't mean "limited 
> types" in the Ada sense). The main limitation, I think, is that the 
> derived type cannot be much more "meaningful" -- that is, carry more 
> information -- than the parent type; if it is, the conversion from parent 
> to derived would have to supply the additional information, from nothing.
>
>> (surely including your enumeration example).
>
> I don't think so, because the "deepened" enumeration type has more 
> information than the parent type. In the example I gave, the derived-type 
> literals Read and Write convert to the parent-type literal Request, but 
> the conversion back from Request to the derived type would have to choose 
> either Read or Write, and it has no information to guide that choice.

Well, the technique still works, and about the same as your proposal: the 
reverse conversion just would raise an exception in the case where it cannot 
figure out what to do. That might be always in some situations, but it might 
also only have to do so in limited circumstances, so there would be more 
flexibility than your specific proposal would give.

The only loss would be a compile-time vs. a run-time check. But that could 
be handled with a way to specify that there is no reverse conversion:

           with Parent_Conversion => My_Function, Reverse_Parent_Conversion 
=> <>, ...

in which case any uses of that conversion would have to be rejected at 
compile-time. (There might be a generic contract problem with this 
particular idea, though.)

                                      Randy.