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

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


I think as much as feasible macros accessing internals should not be in public headers.
OTOH, I think macros purely for portability between platforms, compilers, C/C++ compatibility are fine.

`RUBY3_STATIC_ASSERT` seems harmless (just a help for a messy C/C++ language and portability) but anything poking at the internals of, e.g., RString is harmful.
Harmful because it prevents further optimizations,
it increases maintenance cost as it become time-consuming to remove/change,
it increases the cost for alternative implementations to support it (e.g., TruffleRuby),
and it increase the chance for 3rd-party extensions misusing it (= more bugs).

As we've seen with the so-called "intern.h" header it's now considered public API, so 3rd-party extensions seem to take for granted that anything in public headers is public API.

Could you give some pointers or example of other macros introduced in that change?
Are they mostly about portability, or also about accessing internals?

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

* 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>