[ruby-core:98143] [Ruby master Misc#16803] Discussion: those internal macros reside in public API headers
From:
eregontp@...
Date:
2020-05-05 21:39:22 UTC
List:
ruby-core #98143
Issue #16803 has been updated by Eregon (Benoit Daloze).
shyouhei (Shyouhei Urabe) wrote in #note-6:
> https://github.com/ruby/ruby/pull/3079
Looks a lot clearer to me :)
I think indeed having `ruby/internal/attr/const.h` instead of `ruby/impl/attr/const.h` would be even clearer,
and for the directory name I expect the length to type doesn't matter much.
Regarding @nobu's branch, I see it moves `internal/vm.h` → `include/internal/vm.h` and so we'd have `include/internal/` and `include/ruby/internal/`.
Maybe slightly confusing but I also think it makes sense: both are internal, and of them of `make install`-ed and the other not, just because they need to be for public headers to compile correctly.
----------------------------------------
Misc #16803: Discussion: those internal macros reside in public API headers
https://bugs.ruby-lang.org/issues/16803#change-85385
* 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:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>