Re: static virtual is a keyhole?

>As here the language has to implement both the features, and I see  no sane
>reason to not allow the combination of the otherwise disjunct features.
>
>That well converts to your array example.  Suppose our target is a 2-bit
>processor.  And support was implemented, but with range limited to [0..2],
>as opposed to the limitless coverage of the full addressable range of
>[0..3].
>
>If you thought of case D can you see why we come to different conclusions
>following seemingly the same rationale?

Let me first try to clarify why it's important to me not to stretch the
meaning of "keyhole" too broadly.  To me, all keyholes result from a single
error in thinking: imposition of a gratiutous constraint.  This is almost
always use of a constant where a variable would be better, e.g., showing 11
elements in a listbox regardless of the total number in the listbox and the
amount of available display space; or having a constant-size buffer to hold
a value whose size is variable.  The value in identifying the keyhole PROBLEM
(*singular*) is that it requires that software developers learn only one
thing to be aware of.  Not all gratuitious constraints are keyholes.  For
example, many web pages fix the size of their font.  This is a gratuitous
constraint, but I can't find a way to make it fit the keyhole model.  It's
a different kind of gratuitious constraint, one arising from a different
kind of flawed thinking.  One could argue that it's use of a constant (the
font size) instead of a variable, but the underlying conceptual flaw is
quite different: it's that the web page designer didn't think that users
should have any control over font size.  The underlying conceptual problem
is that of a missing feature, not imposition of a keyhole-like constraint.
So though it's possible to cast fixed-size fonts on web pages into the mold
of a keyhole, I think it dilutes the meaning of a keyhole, hence its
usefulness.  

More specifically to your example, not all combinations of features make
obvious sense.  For example:

  const int x = 10;             // x may be placed in ROM and may not 
                                // be changed

  volatile int y = 10;          // y may not be placed in ROM and may 
                                // change at any time
  
  const volatile int z = 10;    // may z be placed in ROM?  may it be 
                                // changed?

Setting aside what C++ says about the ROMability of z, my point is that
it's not necessarily obvious that const and volatile make sense together.
You say that you see "no sane reason" to disallow the combination, but I'm
guessing that that's because you already know how C++ defines the semantics
of this combination.  Before those semantics were defined, one might argue
that const and volatile were contradictory.

Now, one might imagine a "missing feature combination" keyhole, but my
objection would be that a missing combination of features is not due to the
same kind of underlying conceptual thinking that leads to the things I do
call keyholes.  Again, my goal is not to make the term "keyhole" cover as
many situations as possible.  It's to define the term precisely and
narrowly enough that when somebody says, "Hmmm, you've got a keyhole in
your software here," pretty much everybody knows exactly what that means.

We already have plenty of terms that are so broad, nobody knows what they
mean.  (E.g., "object-oriented," "pattern.")  My preference is to try to
keep that from happening to "keyhole."

Scott