1. parameter type enforcing
Check. You provide a simpler and less-capable interface. Of course it would be easy to add a simple and less-capable interface on top of our general one.
Could you please ground you statement about "less-capable". With specific examples. If you mean something amoung the lines "is_movable" check.
I do.
Look at my responce here:
I saw that. You are basically saying the capability isn't important. We can agree or disagree over that point, but the fact is that the interface you support is still less-capable. I'm trying to bring this back to objective reality.
And I am still disagree. Why is that interface less-capable if I could implement the same logic as with even less keystrokes. Just because you put something into library header doesn't make it more powerfull. It should really bring some advantages and simplify (enhance usebility) function implementation in user's code.
2. default value support
Details, please? Please show the differences (I've clearly lost track of this thread).
template<typename Params> void foo( Params const& p ) { you interface int ind = p[index | 0 ]; my interface int ind = p.has(index) ? p[index] : 0; }
If that's your interface, I don't see how the following statement of yours can also be true:
version you refer to does produce compile time errors facing missing required parameter.
Meaning that if there's no default for index, in your code:
int ind = p[index]; will still compile.
If parameter is *required*, you will get a compile time error . It it optional you may (it's not nessesary though) define default value. Any access to omitted optional parameter would produce runtime error.
3. option parameter support optional actually. Sorry
Details, please?
From other thread:
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] ); }
I'm not sure what you're saying. With the addition of "has" functionality (which we've long ago agreed should be added), you could do this with our design.
No you couldn't . Above wouldn't compile.
We can agree or disagree that this approach is a good idea or not, but the fact remains that your design has no support for non-intrusive overloading (e.g. via ADL).
Could you show me an example of "non-intrusive overloading" and how you design supports it.
4. Unlimited number of parameters support
If I understand what you're saying, no you don't.
Why? I could have as many parameters to function as I want since I do not try to combine under the hood of single keywords structure.
I understand that. I'm saying you don't have a new capability here.
Don't forget, we have the overloaded comma operator.
Don't you still need to use keywords structure?
You don't have to specify it up front unless you want to do overload resolution control.
What about type restrictions?
Okay, thanks, I think I understand your value decisions and design choices here. I was asking because I was concerned that your simpler design might have been an improvement, but I'm now confident we got closer to the sweet spot in the design space, at least from my point of view.
IMO you are yet to show single example that have prove a real advantage of you design. I showed several. All I sew from you so far in not convincing. It's good, that you confident though.
Cheers, -- Dave Abrahams
Gennadiy