Exception transparency - Portable Lambdas
howard.lovatt at gmail.com
Fri Jun 11 19:03:23 PDT 2010
I can't see any evidence that 'exception transparency' as defined in
achievable without immense type cutter, certainly non of the proposals so
far have come close. This is in real danger of turning into 'Variance Mk II'
(as Stephen Colebourne has aptly coined it), which I
assume everyone contributing here wishes to avoid. On a personal note, the
number one reason I give my time for free on this forum is in the hope of
avoiding another disaster like variance. I would suggest that work on
'exception transparency' ceases until a sensible source code representation
can be found, otherwise this will either result in Variance Mk II or
ultimately will not make it into the language (either way, no point
continuing until the first problem is solved).
Stephen Colebourne and Reinier Zwitserlloot have both suggested alternatives
that I find much more appealing than 'exception transparency'. Yes; they
don't provide 'exception transparency' as defined, but they are interesting
pieces of lateral thinking in the same problem space. Personally I would go
further and adopt a variation on Reinier Portable Closures, which he defines
"There are portable closures [lambdas] which have no restrictions of any
kind but which are truly like portable code blocks; a simpler syntax for
today's anonymous inner classes. They cannot capture (mutable) variables, do
not and will never support long return/break/continue, have no exception
transparency of any kind, but you can store them for later, move them to
another thread, and otherwise treat them as one would any random object."
The variation I would add is that a Portable Lambda cannot throw a checked
exception unless it implements a SAM type that does. To be clear about this,
I am proposing that the syntax proposed for lambda types, #name( arg_types
)(throws exceptions), drops the throws clause and hence checked exceptions.
This proposal of Portable Lambda has the advantages of simplicity and
focusing on the sweet spot of usage (parallel code). Users of other
languages with closures, e.g. Scala, don't find the restriction of no
checked exceptions a hindrance (in fact many argue it is an advantage).
Note: the proposal doesn't break old code because a checked exception is
allowed for a SAM.
More information about the lambda-dev