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

Issue #16803 has been updated by shyouhei (Shyouhei Urabe).


Eregon (Benoit Daloze) wrote in #note-1:
> Could you give some pointers or example of other macros introduced in that change?
> Are they mostly about portability, or also about accessing internals?

Almost every new macros are for portability.  For instance `RUBY3_HAS_BUILTIN` is another macro that got publicised this time.  Its former name was `__has_builtin`, which of course mimics clang behaviour for everybody else.  There are also newly introduced inline functions.  They are refactored bits of former macros, hence they touch internals of e.g. RString.

If you want the complete list, new macros are:

```
git grep '^# *define RUBY3.*[^H]$'
```

and new inline functions are:

```
git grep '^ruby3_.*)$'
```

Also, I left this paragraph to every new header files introduced:

> Symbols   prefixed   with   either  `RUBY3`   or   `ruby3`   are
> implementation details.   Don't take  them as canon.  They could
> rapidly appear then vanish.  The name (path) of this header file
> is also an  implementation detail.  Do not expect  it to persist
> at the place it is now.  Developers are free to move it anywhere
> anytime at will.

I believe I made it clear that 3rd parties shall never use those names.  No enforcement though.

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

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