Re: Question[s] about aliased extended return.

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wnhlszemule2fv@cardamome...
...
>> No. Allowing "aliased" at all was a bug in Ada 2005; we preserved it only
>> for compatibility (some GNAT customers used it a lot).
>
>Why not list it in the Obsolescent Features section?

Obviously, if customers are using it enough to make this an issue, it's 
useful in some cases. And there is no alternative if you have to have a 
pointer to match some idiot API, so it's hard to call it obsolescent.

We believe that it can make sense to use for any object that requires 
build-in-place, which is where the "immutably limited" rule comes from, but 
it doesn't make sense if a temporary is involved. But that's all 
after-the-fact thinking; no one considered the implications when it 
originally put into the syntax and there doesn't appear to have been any 
original reason to allow it other than consistency with normal object 
declarations. (But whoever came up with that left out "constant", so they 
didn't do that very well, either.) Since the semantics don't make sense in 
general, and there was no identified need, it shouldn't have been there in 
the first place. The situation is different now, as the OP's example shows; 
since it was there, people figured out ways to use it.

                                                       Randy.