Exception transparency

[Reinier Zwitserloot]

You can compose at will; however, when you do, that closure loses its
restricted property. Composition *WITH* exception transparency vs. losing
exception transparency when composing, but none of the problems raised in
this thread so far, regarding inference, boilerplatey and confusing method
signatured, etcetera.

--Reinier Zwitserloot



On Tue, Jun 8, 2010 at 2:48 PM, Osvaldo Doederlein <opinali at gmail.com>wrote:

> 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.
>>
>>
>