[libcxx-commits] [PATCH] D117811: [libc++] Remove _VSTD

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a reviewer: libc++ vendors.
ldionne accepted this revision as: ldionne.
ldionne added a comment.

I think there is some misunderstanding around `_VSTD::`, `_LIBCPP_ABI_NAMESPACE`, and the notion that libc++ uses an unversioned namespace on purpose in a few places (notably libc++abi). Let me try to clear this up. First:

- `_VSTD::` expands to `std::<abi-namespace>`, and can't be configured.
- `_LIBCPP_ABI_NAMESPACE` expands to `<abi-namespace>`, and is configurable.

However, because of inline namespaces, typing `std::<abi-namespace>::foo` and `std::foo` is strictly equivalent. Therefore, `_VSTD::foo` and `std::foo` are strictly equivalent __for anything that was defined inside `<abi-namespace>`__. There are some places, e.g. libc++abi, where we define types and functions inside `namespace std { }` __without__ using `<abi-namespace>`. As far as I can tell, that was to be compatible with libstdc++ exceptions when we made the migration from libstdc++ to libc++ on Apple platforms ~10 years ago. Because these types and functions are not defined in `std::<abi-namespace>`, `_VSTD` cannot be used for qualifying them, because that would try to access them inside the `<abi-namespace>`. However, the other way around does work, i.e. using `std::` in place of `_VSTD::`.

In particular, this patch does not propose removing the ability to customize the ABI namespace by changing `_LIBCPP_ABI_NAMESPACE`. That would still be supported, and if you customize `<abi-namespace>`, we'd still be using the correct namespace when doing `std::foo`, whether `foo` is a versioned symbol or not.

My main rationale for being in favour of this change is that we don't even use `_VSTD::` consistently, and so any claims to be using `_VSTD::` in fancy ways is guaranteed not to work without changes (and I suspect pretty major ones). In other words, I think we're cargo-culting the utility of this macro, and I would like to see it go away. I'm adding the `libcxx vendors` group to gather attention. If you can bring new information to the table (e.g. if you can show us reasonable uses of `_VSTD` that I am not aware of), then we can totally have this discussion, and we could even perhaps support that use case properly. However, I would really like to avoid making progress on this just based on fear and uncertainty.

However, my main concern is about breaking in-flight changes and downstream diffs by making such a wide ranging patch (I would have the same concern for e.g. `clang-format` on the whole code base at once). Instead, I would like that as a first step, we redefine `_VSTD::` to being just `std::`, and start using `std::` instead of `_VSTD::` in new code we write. We could then also move from `_VSTD::` to `std::` in patches that e.g. modularize files or otherwise touch a lot of lines anyways. I'm accepting personally to show support for this. Let's give folks the opportunity to show concrete evidence of `_VSTD` needing to stay, and if that doesn't happen, we'll move forward.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117811