From: eregontp@... Date: 2020-05-03T14:48:15+00:00 Subject: [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: