On 5/21/18 4:49 PM, Gavin Lambert via Boost wrote:
On 22/05/2018 02:53, Robert Ramey wrote:
I'm strongly opposed to downgrading from safe_bool to implicit bool.
I made my argument why this is good idea. What's wrong with my argument?
Perhaps I missed something, but your argument seemed to be "safe bool doesn't work in newer compilers" (so fine, use explicit bool instead, since newer compilers do support that), and "explicit bool doesn't let me write bad code" (so don't do that).
This would/could break lot's of current code. Basically any code which looks like the following:
bool f() { tribool tb ... return tb; }
which to me looks like a perfectly reasonable thing to do. But using explicit would create a compile time error.
I disagree.
No, that's a perfect example of terrible code that should absolutely generate a compiler error. A narrowing conversion (from a source type that can express more values than the destination type) should absolutely *never* under any circumstances occur implicitly.
I think that tribool is/was designed to promote this and in this case I find it useful and natural.
This is exactly the reason why safe_bool was created in the first place,
safe_bool never corrected this and won't in C++11.
and why explicit bool was corrected in C++11 to match.
I don't think explicit was created to fix safe_bool. In general I support usage of explicit. But in this case I don't think it's a good match.
If you *want* that code to compile, then "return bool(tb);"
Hmmm - I don't think this actually depends upon implicit conversion of tribool to bool.
(or use static_cast if you prefer) instead.
Right. But then I'm imposing your view point on many users programs which already exist. You're basically changing the intention of tribool. You may well have a good argument that the very idea of tribool is a bad idea, that it should never have been made the way it was and that no one should use it, but that ship sailed long, long ago. It's not relevant here. And this will work with both
safe_bool and explicit bool.
I would be ok with #if logic that uses safe_bool on older compilers and explicit bool on C++11 and up.
This to me seems the worst. It would mean that the semantics of tribool vary depending on which standard the compiler is adhering to. It would be impossible to discern the behavior of the code just by looking at it. You'd have to know which compile time switches are being used.
The semantics of explicit bool are the same as the semantics of safe_bool,
No they are not. And that's the exact problem. You can review my example above or check out this short video https://www.youtube.com/watch?v=7uIyl_tDMkM
just better as it has proper compiler support instead of taking advantage of a hack to work around the previous defect in operator bool.
but it's not the same thing.
Personally, the thing I would most prefer is to get rid of any bool conversion at all and require code to explicitly test tribools for ==true/==false/boost::indeterminate,
OK - but neither of us were around 15 years ago when it was reviewed. Unilateral changing it at this point would change the whole design and intention and break existing code. I don't see how that could possibly be acceptable. Of course if you want to make and propose an alternative library named trilleam or something like that you're more than welcome. But we can't trapse all over boost mucking up things wily nilly. The change I propose: a) won't change the current semantics of tribool as it relates to any currently working programs. b) will address a current problem with tribool and gcc c) will "recover" the trapping behavior of safe_bool with C++17 It's really a no-brainer.
as people will usually disagree on whether indeterminate should be truthy or falsy when forced to pick one. But I am not advocating that as I think the ship has long sailed.
Of course if you want to make and propose an alternative library named trilleam or something like that you're more than welcome. But we can't trapse all over boost mucking up things wily nilly. Robert Ramey