You can't implement the same compile-time logic with less keystrokes. It's less capable because our design has a capability that yours doesn't. Not a matter of opinion, just a fact.
The only fact here is that you are making that statement. Let's take you "more-capable" interface and implement solution for simple problem. Let then take my interface and implement the solution for the same problem using my "less-capable" interface. Let than compare which variant is easier and shorter. And that would be *the fact* (it's still matter of taste/preference, but I hope we will be able to see it clearly). Until that time you statement: "You can't implement the same compile-time logic with less keystrokes" *is* a matter of opinion and not a fact.
If parameter is *required*, you will get a compile time error . If it's optional you may (it's not necessary though) define default value. Any access to omitted optional parameter would produce runtime error.
Ah, I understand, now. Thanks. In that case my original statement about your design that "it sacrifices compile-time type safety for runtime checks" is in fact true.
I may say the same thing, but pressing different points: your design sacrifices flexibility and usability for ... compile time switch of function implementation. My design based on a two facts: 1. it's perfectly ok to omit optional parameter in function invocation 2. If parameter is optional why invocation should fail to compile if it's missing? 3. it's ok to switch function implementation at runtime based on presence/absence of function parameter
void foo_impl( int i1, int i2 ) {...} void foo_impl( int i1 ) {...}
template<typename Params> void foo( Params const& p ) { if( p.has(i2) ) foo_impl( p[i1], p[i2] ); else foo_impl( p[i1] ); }
No you couldn't. Above wouldn't compile.
Mmmm.... why not?
Because p[i2] fails to compile if i2 is missing.
Could you show me an example of "non-intrusive overloading" and how you design supports it.
Sorry, like Fermat I don't have time/space to write it down here ;-).
Not even small example? Pseudocode? Pity. I would be much more easier to discuss the differences.
In shorthand, it's the ability to add new overloads of a top-level (public) function template that uses named parameters without changing the implementation of that function.
Do you mean: without need to change other overloads of the same function? You see, it's difficult for me to imagine this situation since in a majority of the cases I would be using *single* public function: foo( Params const& ) that cover all possible combinations of parameters. If you could just explain (give an example) when I would need more.
4. Unlimited number of parameters support What about type restrictions?
If you want them, you specify it.
IOW library wouldn't be able to provide automatic support for this.
So maybe you have a way to specify type restrictions without building a keywords structure, although you do require people to bind the type restriction into the keyword itself. I admit that is a design difference.
So you solution either force limit on number of parameter or does not provide automatic type checking. Is this right?
IMO you are yet to show single example that have prove a real advantage of you design.
I am not out to prove it to you. I never try to change the opinion of someone whose mind is already made up.
That the examples I have shown don't convince you is not surprising.
Did you? Did I missed them?
It's good, that you confident though.
Your sarcasm is unwarranted.
Well. Since you believe you are allowed to state "I am confident, that I am right", I believe I am allowed to be a bit sarcastic (especially since I feel that you statement does not have enough foundations)
-- Dave Abrahams