"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
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.
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.
Just because you put something into library header doesn't make it more powerfull.
I didn't say it was more powerful. I said it was more capable.
It should really bring some advantages and simplify (enhance usebility) function implementation in user's code.
Maybe so. Whether or not the advantages I think the capability brings are real or not appears to be a matter of opinion. The fact that the capability is in our design and not in yours is, well... a fact.
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.
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.
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.
Mmmm.... why not?
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.
Sorry, like Fermat I don't have time/space to write it down here ;-). 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.
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?
If you want them, you specify it. 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.
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 am not out to prove it to you. I never try to change the opinion of someone whose mind is already made up.
I showed several. All I sew from you so far in not convincing.
:^). That the examples I have shown don't convince you is not surprising. Likewise, none of the examples you've shown are convincing to me, although at the beginning of this exchange I was prepared to believe you had done something worthy of attention.
It's good, that you confident though.
Your sarcasm is unwarranted. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com