Exception transparency

[Osvaldo Doederlein]

Just adding $2c, the advantage of being composable should clearly be the
highest priority at least in some extent: lambdas must support this quality
at least well enough to match the existing mechanism that they replace
(interfaces / SAM types / inner classes); for example you can put those
inside collections without losing any type-safety, so any flavor of lambda
that doesn't allow that is D.O.A.

A+
Osvaldo

2010/6/8 Neal Gafter <neal at gafter.com>

> On Mon, Jun 7, 2010 at 9:53 PM, Reinier Zwitserloot <
> reinier at zwitserloot.com
> > wrote:
>
> > Making the exceptions transparent by encoding them in the type system is
> > going to be very unwieldy, even if a "throws T" variadic type parameter
> > concept is introduced. I've got a much better idea: Escape detection on
> > closures. Any closures that are guaranteed to run such that the runtime
> > stack matches the lexical stack can get exception transparency completely
> > free, no new syntax and no new concepts required; it would "just work".
> >
>
> Reinier: your scheme, even assuming it could be checked at compile-time,
> does not work for functions that are to be stored in variables or in a data
> structure (for example, a collection of callback functions).  It is not
> composable.
>
>