Return Isn't Transparent

[Neal Gafter]

Howard-

These are not difficult cases at all - they are not supposed to be
"transparent".  In these cases the programmer has explicitly selected a type
to store the lambda that discards information about the lambda's completion
status.  That is both legal and allowed, and sometimes useful.  Transparency
does not and should not prevent that.  Transparency makes it possible to
select a type (or have a type selected by type inference) that does not
discard that information.

Cheers,
Neal

On Tue, Jul 20, 2010 at 5:58 PM, Howard Lovatt <howard.lovatt at gmail.com>wrote:

> @Neal,
>
> Building on Reinier suggestion:
>
>        private static int m6() {
>                final { boolean ==> void } return42 = { boolean b ==> if ( b
> ) {
> return 42; } };
>                final { boolean ==> void } returnNot41 = { boolean b ==> if
> ( !b ) {
> return 41; } };
>                return42.invoke( true );
>                returnNot41.invoke( true );
>        }
>
> Presumably for difficult examples like this you would have no
> expectation of them working, which was my point that in general you
> can't have return transparency because analyzing the expressions is
> too difficult for the compiler.
>
>  -- Howrad.
>
> On 21 July 2010 02:06, Neal Gafter <neal at gafter.com> wrote:
> > On Tue, Jul 20, 2010 at 8:55 AM, Reinier Zwitserloot
> > <reinier at zwitserloot.com> wrote:
> >>
> >> What happens when the closure isn't ===> Nothing, but ===> Void, e.g. to
> >> fit the parameter type of a bggaBasedForEach() method?
> >
> > Invoking something that is declared to return Void is considered by the
> > compiler to be capable of completing normally.  That's what you want for
> a
> > for-each loop: a loop can complete normally even if its iterations can't,
> > because it may execute zero iterations.
> >
> > -Neal
>
>
>
> --
>   -- Howard.
>