Re: another way to shoot yourself in the foot?

[george.priv@gmail.com]

On Jun 23, 3:49 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 22 Jun 2008 16:44:08 -0400, Robert A Duff wrote:
> > I don't see that as a problem, and anyway, the same thing can happen
> > with the existing syntax:
>
> > function Foo (...) return String is
> > begin
> >    return Result : String (1..200) do  -- Going to return 200 characters
> >       Result (1) := 'a'; -- Here the result has to be allocated
> >       if HALT (x) then
> >          goto Label;
> >       end if;
> >    end;  -- Drop already allocated and initialized result
> >    <<Label>>
> >    return "Hallo!";  -- Return a completely different thing
> > end Foo;
>
> > The implementation of this is "interesting" (if we replace String by a
> > build-in-place type).  ;-)
>
> How much interesting is it? (:-))
>
> Unfortunately the following crazy sample crashes GNAT, but I wonder what
> could be the result if it compiled:
>
> procedure Return_Task is
>    Just_For_Fun : exception;
>
>    task type T is
>       entry A;
>    end T;
>
>    task body T is
>    begin
>       accept A;
>    end T;
>
>    function Interesting return T is
>    begin
>       return X : T do
>          raise Just_For_Fun;
>       end return;
>    exception
>       when Just_For_Fun =>
>          return X : T;
>    end Interesting;
>
>    X : T := Interesting;
> begin
>    X.A;
> end Return_Task;
>
> Should it block?
>
> Another question is about the semantics such stuff. In which sense in-place
> is it? It seems that an in-place initialization might result in n
> finalizations and n+1 initializations (n>=0) of the same thing.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Aren't tasks limited types by definitions? In which case compiler
should be giving error message..