Context-based overloading

It seems that it might not be that involved to extend the object-oriented programming feature of function overloading based on object type to include overloading based on other contextual aspects like target ISA/microarchitecture. Digital Mars' D programming language provides a version feature which allows conditional compilation based on ISA and OS, though microarchitectural features are not included. The pre-defined version names also appear to be flat; some degree of hierarchy might be appropriate. Defining such with classes and objects could allow inheritance (e.g., Linux could inherit from Posix [but not necessarily from Posix-strict] and Nehalem could inherit from x86-64), possibly simplifying management of such names.

As a non-programmer who thinks about programming language design [i.e., an ignoramus but not a complete ignoramus], I think a more elegant expression of such conditional compilation might be to use any statement that evaluates to a boolean compile-time constant as a control for block compilation. The D programming language provides static if, but a short hand form of static if could simply include the expression. Of course, one could then simply provide that syntax for all conditional blocks. It seems that this would also extend to switch-like statements, perhaps along the lines of:

some_function(function_argument)  // returns a positive integer
{
   == 1 
   {
      do_things_for_1
   }
   == 2
   {
      do_things_for_2
   }
   < 7
   {
      do_things_for_3_through_6 // note this assumes an
                                // explicit fall through
                                // requirement
   }
   else
   {
      do_things_for_other_cases
   }
}

That might not be a good extension, however.

Using a static keyword does force the compiler to guarantee that the expression can be evaluated at compile time. While an advanced development environment would be able to express the compile-time constant nature of an expression (at least for simple cases), there might be some advantage to explicitly indicating the static nature.

If the C programming language had used ~ for boolean inversion as well as bitwise complement instead of !, then ! might be used as an assert-like indicater, possibly with pre-assert and post-assert forms (analogous to pre-increment and post-increment; pre-assert would be evaluated at compile time, post-assert at run time). Without an associated block, such would act like an assert; with an associated block, such indicate a forcefulness along the lines of "if such is true--and it almost certainly is--then".)

As an extension (and one that might be compatible with C programmers), one could use ? in its pre-expression form to communicate a compile-time hint (like the above pre-assert) that the code in the associated block might be suitable if the expression evaluates to true but the compiler can override that hint (whereas a pre-assert forces the compiler to use the code if the expression is true). One might be able to use a duplication of the symbol to express emphasis, i.e. ?? in prefix form might indicate a low-confidence hint and in postfix form might indicate a low-probability condition; likewise (if one could use the symbol in that way without confusing programmers) !! in postfix form might indicate "almost certain" (and without an associated block it might indicate a higher level exception or more critical failure), though I am not certain what meaning such should have in prefix form (overriding later overloading--a bit like CSS !important--might make sense, but seems a bit dangerous).