Exception transparency - lone throws (no checked exceptions)

[Reinier Zwitserloot]

This observation by Stephen was worth repeating:

My aim is to avoid the horrific syntax that exception abstraction
> requires. If someone can show a sensible approach at the syntax level
> for function types and methods that need to be transparent, then I
> have no objection to the basic direction of the strawman. I simply
> don't believe such a syntax exists.
>

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. 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. However, between explicit ET and
implicit-for-impure ET, I'm saying the value proposition isn't worth it; the
jump in complexity from implicit-for-impure to explicit is gigantic, and the
added expressiveness is relatively small. You have a tendency to claim
certain use cases MUST be supported and any proposal that can't do it
doesn't even bear thinking about (such as Tennent's Correspondence
Principle), but, for example, long breaks/returns/continue is out, at least
for now, most likely because the complexity added is considerable.

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.

Which just goes to show how fluid these proposals can be: Pure/impure
removes complexity and makes return/break/continue transparency much
simpler, but it makes use-cases involving the storage of closures much more
difficult. So, it's a trade-off. I don't think talking about such things in
absolute terms are a fruitful exercise. Is it a good trade-off - that's the
question. I believe it will be, by a mile, but I might be wrong.