[ruby-core:98128] [Ruby master Misc#16803] Discussion: those internal macros reside in public API headers

Issue #16803 has been updated by Eregon (Benoit Daloze).


shyouhei (Shyouhei Urabe) wrote in #note-4:
> What about those names, like `ruby_impl` or even, `rbimpl`?

I think those are already much clearer than `ruby3_`.
`ruby_internal_` might be even clearer but indeed it's long.

I think `rbimpl_` is a good compromise.
Would it be OK to change the prefix to that?
I think it's a great improvement over the `ruby3_` prefix.

To help comparing visually:
```c
static inline long
rb_fix2long(VALUE x)
{
    if (ruby3_right_shift_is_arithmetic_p()) {
        return ruby3_fix2long_by_shift(x);
    }

    if (ruby_impl_right_shift_is_arithmetic_p()) {
        return ruby_impl_fix2long_by_shift(x);
    }

    if (rbimpl_right_shift_is_arithmetic_p()) {
        return rbimpl_fix2long_by_shift(x);
    }

    if (ruby_internal_right_shift_is_arithmetic_p()) {
        return ruby_internal_fix2long_by_shift(x);
    }
```


----------------------------------------
Misc #16803: Discussion: those internal macros reside in public API headers
https://bugs.ruby-lang.org/issues/16803#change-85371

* Author: shyouhei (Shyouhei Urabe)
* Status: Open
* Priority: Normal
----------------------------------------
A while ago I merged https://github.com/ruby/ruby/pull/2991 ("Split ruby.h").  This seems working.  But the changeset raised several questions.

The biggest one relates to those newly publicised macros and inline functions.  For instance `RUBY3_STATIC_ASSERT` is a macro that expands to either `_Static_assert` (for C) or `static_assert` (for C++).  A similar mechanism has been implemented inside of our repository for a while.  The pull request moved the definition around to be visible outside.

#### Discussion #1 ####

Is it a good idea or a bad idea, to make them visible worldwide?

#### Discussion #2 ####

Why not publicise everything?  For instance debuggers could benefit from ruby internal symbols.

#### Discussion #3 ####

It is relatively hard for us to change public APIs (doing so could break 3rd party gems).  We don't want that happen for internal APIs.  How do we achieve future flexibility?



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>