Exception transparency - lone throws (no checked exceptions)

[Neal Gafter]

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

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