Hello Yigal,
everything you said is true. there is some sort of a compile-time
since
the code is getting compiled. But in the above scheme there isn't any
real difference between run-time and compile-time and this distinction
has lost its meaning.
compare the following:
process A:
1) use runtime dispatch based on run-time user input
2) generate source code for the above case "on the fly"
2) compile the above code and call it
process B:
1) generete templated source code at runtime
2) call run-time compiler module on the above code
3) compiler instantiates the template based on the input at
*compile-time* (i.e. compile time dispatch)
4) call the templated instance
the above are identical even if implemented differently since that
compile-time above is actually part of the run-time.
the only difference is the style of coding and I'd argue that the
second
process is unnecessarily more complex without any gains.
if nothing else than the source code generated will be shorter since
you
wouldn't need to stick "static" everywhere.
I think you understand my point about what is possible but I'm not sure you
are spotting what I'm saying regarding what should be done. I'll try and
cleanly state what I'm asserting:
a number of red hearings seem to be floating about based on cool uses for
truly runtime dynamic function lookup (that we just agreed doesn't exist
for the given syntax as for that case, the binding happens at sort sort of
compile time). I'm calling them red herrings because those uses can be done
with other functionalties that already exist.
If we throw those out, the only new functionality remanding that any of this
thread has provided is allowing the following syntax:
a.b(args);
to be used when the type of 'a' doesn't define a 'b'. What a lot of debate
seems to be about is if that should be translated to:
a.opDotExp("b", args);
or
a.opDotExp!("b", typeof(args))(args);
but that's an easy question (go with option 2) if you note that the transformation
is always at /some sort/ of compile time. If you want this and the non-static
(a.k.a. the non compile time binding (where you thinking of static like static
member and not static if/assert?)) form you can implement the non-static
version using existing devices and make the above a trivial shell around.
Trying to go the other way doesn't work as there is no way to make static
decisions (static if or template specialization) in a purely runtime mode
using runtime values.
[ot] the annoying thing about this whole thread is that I'd bet a small amount
of money that I could convince anyone here of my point in about 5 minuets
if I had me, them and a chalkboard in the same room. I think almost all the
confusion is not because people would disagree with what I'm trying to say
but because there are about 5 different and almost unconnected things people
are arguing about: a sort of "A is true"/"No, B is true" where A != B and
A != !B and !A != B ...
Written language has the advantage that you can be very precise and thought
out but has zero real time feedback like you get in a face-to-face and an
insanely long delay for what feedback it does have.
