[libcxx-commits] [PATCH] D126249: [libc++] Remove _LIBCPP_ALIGNOF

[Nikolas Klauser via Phabricator via libcxx-commits]

philnik added a comment.

> - If the compiler ever wants to support `alignof` as an extension in C++03, we'll need coordination between the library and the compiler.

That could be avoided by checking for `#if defined(_LIBCPP_CXX03_LANG) && !__has_keyword(alignof)` instead of just `#ifdef _LIBCPP_CXX03_LANG`.

> - This is technically a breaking change for C++03 users because they are allowed to use `alignof` as a name, and we're not allowed to define identifiers outside of our namespace. Concretely, I do suspect this may break some C-first codebases that try to be clever.

C++03 in libc++ is more a crutch than anything else at this point. Users are also allowed to `#define` a lot of names in C++03 that we use in the library and are only part of C++11.

These are the keywords introduced in C++11 (according to https://en.cppreference.com/w/cpp/keyword):

| **Keyword**     | **Provided?/How?** |
| `alignas`       | not provided       |
| `alignof`       | not provided       |
| `char16_t`      | typedef in libc++  |
| `char32_t`      | typedef in libc++  |
| `constexpr`     | not provided       |
| `decltype`      | macro in libc++    |
| `noexcept`      | not provided       |
| `nullptr`       | macro in libc++    |
| `static_assert` | macro in libc++    |
| `thread_local`  | not provided       |
|

So we already define quite a few C++11 keywords. Functionality wise most of them are indistinguishable from their C++11 keyword versions. We can't provide `constexpr` and `noexcept` because we don't have a way to emulate them. We don't use `thread_local` anywhere so I don't particularly care. So effectively the only ones left are `alignas` and `alignof`.

I think the C-first codebase that this change would break are very few and are arguably broken already. We would also break these codebases if we included `stdalign.h` and they are definitely broken by C23 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2654.pdf).

> - This breaks the symmetry between `_LIBCPP_PREFERRED_ALIGNOF` and `_LIBCPP_ALIGNOF`.

There are exactly 3 uses of `_LIBCPP_PREFERRED_ALIGNOF`, all of which are in `<type_traits>`. I think removing the macro and adding a comment on these places is the better alternative.

> - We have experience that defining compiler stuff in the library isn't a great idea -- for example, we've yet to figure out a way to get rid of our `char16_t` typedef, and it's not even a macro.

I think getting rid of a macro that emulates a keyword is easier than a `typedef`. The `typedef` has ABI implications which simply don't exist with these macros.

> All in all, I feel that this change doesn't pull its weight, even though I am supportive of the intent. Thoughts?

I know we don't want to break users, but I think we should treat C++03 as what it is: A relic of a bygone era and a burden nobody wants to keep.
It seems like a thing almost nobody uses but nobody knows how many users there are, so we don't want to risk just throwing it away. It's not like it makes sense to have a standard library from 2022 and using it with a language standard from 2003 (or more like 1998). People had over a decade of time to upgrade by now and people who haven't won't use any even nearly up-to date toolchain. Let them deal with it in 20 years when they finally decide to upgrade. (If you didn't notice by now: I want to get rid of C++03)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126249/new/

https://reviews.llvm.org/D126249