object.c: rb_eql returns int not VALUE

[casperisfine]

It works, but assumes Qfalse == 0, which is true today but might not be forever.

[nobu]

This change seems reasonable, but I'm strongly against changing Qfalse itself.

[rhenium]

The doc comment in include/ruby/internal/intern/object.h needs to be updated to reflect this change.

Apparently, rb_eql() actually used RTEST() before commit b827fdf (2017, Ruby 2.5).

[casperisfine]

I'm strongly against changing Qfalse itself.

That change is not in order yet and would be complicated, but we may want to do it one day: https://bugs.ruby-lang.org/issues/18397

The main reason for the change here is the incompatible types. I just saw this while looking at something else and was really surprised.

The doc comment in include/ruby/internal/intern/object.h needs to be updated to reflect this change.

Oh wow:

/**
 * Checks for equality of the passed objects, in terms of `Object#eql?`.
 *
 * @param[in]  lhs          Comparison left hand side.
 * @param[in]  rhs          Comparison right hand side.
 * @retval     RUBY_Qtrue   They are equal.
 * @retval     RUBY_Qfalse  Otherwise.
 * @note       This  function  actually  calls `lhs.eql?(rhs)`  so  you  cannot
 *             implement your class' `#eql?` method using it.
 */
int rb_eql(VALUE lhs, VALUE rhs);

This doc make little sense to me. And to be fair I don't understand why int rb_eql vs VALUE rb_equal.

Was this function meant to be VALUE rb_eql or something?

Should I open an issue for this to be calrified?

[casperisfine]

Ok, so this documentation was only added very recently in d43acca

So I think explicitly documenting Qfalse / Qtrue wasn't particularly intended. I'll update the documentation.

[nobu]

Non-zero feels better than 1, to not expect it too restricted.