a doc patch will not be necessary if this is accepted. What I meant was that this commit also adds to the documentation that a boolean is a valid class (previously undocumented) and if the fix got rejected for some reason, a separate would have to be done for it.
Anyway, I have been thinking about this since I made the change and I wish to further change this. I may be seeing Result in the wrong light, but in my mind it's not unlike an if block and we shouldn't restrict it to certain classes. Leave it to the user to pick anything that can be evaluated as true or false and only act special in the case of a string. If you agree, I can submit another patch for something like:
That is better, I agree. It will also treat empty lists and hashes as "no" which I think is fine. (Alternatively, list types could throw an exception, but I think that's not necessary.) Feel free to update your pull request.
I have updated the pull request. What I implemented is a bit different that what I mentioned on the previous comment, it won't check for true/false if it's a string. This is compatible with the previous behaviour for strings (empty strings, display empty string, not the word "no").