Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve compiler issues for common compiler configurations #42

Open
jwhpryor opened this issue Feb 3, 2023 · 1 comment
Open

Resolve compiler issues for common compiler configurations #42

jwhpryor opened this issue Feb 3, 2023 · 1 comment
Assignees
Labels
good first issue Good for newcomers
Milestone

Comments

@jwhpryor
Copy link
Collaborator

jwhpryor commented Feb 3, 2023

Some common compilers (such as those bundled with the Android NDK on stock Bazel) have outdated or non-conformant clang implementations.

Some of these legal but unsupported syntaxes could be obviated with equivalent but supported implementations.

@jwhpryor
Copy link
Collaborator Author

Some of this may be impossible without either changing the call syntax or waiting until the library can support C++20.

There are a couple alternatives:

  1. Provide a slower solution for non-clang alternatives. This could likely be reduced to a single dereference per method invocation (the correct idx can still be inferred compile time).
  2. A syntax that explicitly requires providing the idx as a template argument based on a constexpr method invoked from the constexpr class. E.g.

LocalObject<kClass> obj {}.Call<kClass.idx("Foo">(...);

This introduces a lot of duplication and isn't visually appealing.

  1. Wait until C++ 20string literals are available and cut a library release that isn't backwards compatible.

Relevant links:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0424r2.pdf
http://je4d.s3.amazonaws.com/D0732R0-wip.pdf
https://artificial-mind.net/blog/2020/11/14/cpp17-consteval

Even still, this option may require a new syntax because operators can't be cleanly templated. E.g. you may need to write the syntax:

obj.template<"Foo">( ... );

Here at least we could offer a new syntax:

obj.Call<"Foo">( ... );

This would maintain dual compatibility but would be sad to introduce a new call syntax. It's unclear to me if consteval could provide a consistent syntax to what exists today.

  1. Look for a gcc equivalent of the function argument enable_if. This isn't particularly good long term either though.

What's unfortunate is that the correct idx can be inferred at compile time at the call site, but not once the member method has been invoked. C++17 has everything it needs.

I don't think this is trivial to resolve, so, I will leave this as an open problem, but not blocking for release. I tried every trick I had.

@jwhpryor jwhpryor removed the Release label Mar 23, 2023
@jwhpryor jwhpryor removed this from the Release 1.0 milestone Nov 18, 2023
@jwhpryor jwhpryor self-assigned this Feb 24, 2024
@jwhpryor jwhpryor added this to the Release 2.0 milestone Mar 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant