Virtual extension methods - syntax options

[Neal Gafter]

On Wed, Jun 16, 2010 at 3:48 PM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> I've written down an alternative exception transparency proposal in this
> mailing list based on pure/impure closures.

I don't remember anything like a draft specification for the approach
you're suggesting, which perhaps explains why I thought that it
undermines exception checking.  Can you please provide a link to the
archived message in which you posted it?

> Perhaps you can
> show us a set of examples that will suggest that this use case isn't nearly
> as rare as I think it is. Either way the decision isn't black and white;
> it's a matter of how many use cases are "lost" (can no longer be done
> cleanly) compared to exactly how syntactically and semantically complex one
> considers the explicit "throws E" concept.

You're trying to draw me into a language design exercise based on
inappropriate criteria.  We cannot know ahead of time how many uses of
the language feature will depend critically on which aspects of the
feature.  See <http://gafter.blogspot.com/2006/09/failure-of-imagination-in-language_17.html>.

Still, I've built a generic visitor-like framework in BGGA that is an
API to which one adds filter-processor pairs, and at the end applies
the whole set to an input object.  The framework supports exception
transparency.  Since the filter-processor pairs must be stored, the
only way to support checked exceptions throwing through the API is for
the type system to express them.