Exception transparency - lone throws (no checked exceptions)
neal at gafter.com
Wed Jun 16 15:10:40 PDT 2010
On Wed, Jun 16, 2010 at 10:03 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
=> Neal, I've admitted that the syntax-based exception transparency plan no
> doubt handles the most use cases of the 3 solutions offered (explicit,
> implicit-for-impure, lone throws) However, I've also said that the frequency
> of cases that it can handle that my pure/impure concept can't is most likely
> rather small, whereas the extra complexity required is enormous, and not
> just for the compiler builders - generics is still a source of never-ending
It's not merely a matter of not handling the cases, notwithstanding
the inaccuracy of your guesses about their frequency. Undermining
compile-time exception checking is a nonstarter.
> In the case of generics I don't know of any proposal that gave us
> most of the power without most of the complexity, but if it HAD come along
> it might well have been the better choice. There was no such proposal, the
> considerable added complexity was nevertheless worth doing because the added
> expressiveness outpaced the complexity.
The alternative was called declaration-site variance, but because it
would not have allowed the existing collection classes to be
retrofitted it was rejected as an option.
> Incidentally, pure/impure closures make adding return/break/continue
> transparency very simple; all that needs to be done then is invent new
> syntax to be able to specify the target of a return statement, somehow,
> either by letting you explicitly target them e.g. with labels like you can
> with breaks/continues, or by inventing a new syntax for local return.
This paragraph doesn't make sense. I suspect you don't know what
"transparency" means in the context in which you are attempting to use
More information about the lambda-dev