Stewart, Robert <Robert.Stewart <at> sig.com> writes:
Your examples from English are valid (though my spelling checker wants to change "cellphone" to "cell phone" .
Yes, 'dictionary.com' insists on them being separate... but, in fact, that was in part my point -- language is a living thing, words get together, move in and out. Some compound words which used to properly written with a dash (like multi-storey) are losing dashes. Some never even had the dashes (like 'file name') but still got together anyway. For many something like file_name will not probably look right. That said, I renamed safebool to safe_bool :-) so that we could pass that point.
...
{ return safebool<Foo>(c); } { return safebool<Foo>::apply(c); }
The former relies on creating a temporary and accessing a nested type, ... The latter involves a static member function, ... It's just a more straightforward mechanism with more consistency between the return type and invocation, together making it slightly nicer.
I actually agree with you... but that's implementation detail that the user does not care or deal with. As for the interface due to utter simplicity of that safe_bool I'd like it to be deployable with as little effort as possible. Therefore, I feel from the *user* point of view the former wins over the latter.
I agree with Steven. One interface is sufficient. It would be nice to have more opinions, however.
For the time being I'll keep both (as above).
I expect this will warrant a fast-track review, but you could hope for more opinions at that time, since few are available now.
Yes, I prefer spelling safebool<> for consistency.
From that response, I'm unsure whether you took my point. To be clear, given
Yes, a fast-track review makes sense and would be nice... or just a review. :-) You might have noticed I was not exactly lucky getting to the review phase. :-) I am probably missing some important process steps (although I did read the relevant pages). If you could give me a hand with that, it'd be much appreciated and I'd know how to do it properly without irking people. the choices,
1) safe_bool<Foo>::apply(c) and 2) make_safe_bool(this, c),
and the conversion type,
safe_bool<Foo>::type,
1) is more consistent than 2), so we should eliminate 2).
Sorry for being unclear. Yes, I like and implemented #1. The 'make_...' has been removed altogether. Best, V.