Since you as usual did not provide an example, I may only guess that by "SFINAE support" you mean the way to implement kind of type checking. In my case I do not need that, cause I would be using typed keyword instead.
Just read the documentation.
I did. And it does not make too much sense to me. From what I gather you are using it to control overload resolution and /or to restrict types of a parameter. What overloads are you trying to resolve here: template<class A0> void foo( const A0& a0 , foo_keywords::restrict<A0>::type x = foo_keywords() ) { foo_impl(x(a0)); } template<class A0, class A1> void foo( const A0& a0, const A1& a1 , foo_keywords::restrict<A0,A1>::type x = foo_keywords() ) { foo_impl(x(a0, a1)); } As for type restriction I am using typed keywords.
Or do you think enable_if<> can be replaced by just not using templates as well?
I have no idea what you mean here. Unless you type some actual example for dummies (like me) it's all meaningless IMO.
Positional parameters in the sense that they can be supplied either by name or position.
I don't really like the idea to mix positional and named parameters this way anyway (see my other post), so wouldn't even try to implement it. Especially considering how much it cost to implement. Though you right: I do not support it as it is.
and the fatal design mistake of treating missing required arguments as runtime errors.
Well, I believe that compile time errors are at least an inconvenience and at most "fatal design mistake". Here is couple reasons why (you 'forgot' to mention any reasons for you opinion, but still)
Yeah well, the reasons should be obvious for anyone that uses C++. As Rene has already pointed out in another thread.
1. Named parameter interface is assumes optional parameter in most cases. IOW we have function with variable optional number of parameters. Fact
I use C++ (surprise, surprise) a lot. And I do not believe that absence of optional function parameter is compile time error. that
one is not present is not an error, but a valid call. Now lets look how would you implement this function:
template<Params> foo( Params const& p ) {
Here you either use MP if or regular if to switch to appropriate implementation. I find regular if *much* more convenient and easier to understand and implement
I would use the normal way of disabling function template overloads; SFINAE.
Ok. Here is an example: 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] ); } Above is my solution to the resolving overloads based on presence of optional named function parameter. Could you type below how would yours look like?
int v = params.has(a) ? params[s] : 8; Then any other compile time interface you would invent.
I'm assuming you mistyped that, in which case it's spelled:
No, it's exactly like it supposed to be
int v = params[a | 8];
With our library.
And now compare: what is more obvious and easier to grasp?
3. Separation if implementation and invocation. The fact that you want to detect access to missing parameter at compile time assumes that during compiling if function invocation you have an access to function implementation.
No of course it doesn't assume that. The keyword parameters is part of the function *interface*, not the implementation.
The complete list of them - yes. But which one of them are optional, required or conditionally required is completely in function implementation domain.
IMO this is bad assumption in general and may not be the case in a future (with different implementation if templates). Don't take me wrong there some things we do want to check at compile time. But here we talking abut function implementation details, which caller do not need to know.
No, we are talking about the function interface, which the caller most likely should know about.
How are you supposed to now from 'select' function interface that timeout parameter is required iff mode parameter is WAIT? Accordingly in a point of select function invocation: select(( more =WAIT,priority=2,prefer_output=true)); You have no way to know that timeout is missing, while in following call select(( more =POOL,priority=0)); is not.
I'm done in this thread now.
.. I couldn't restrain myself.
I like this practice: during review just ignore all negative reviewers, hopefully people would missed it. Sorry, couldn't restrain myself.
-- Daniel Wallin
Gennadiy