[libcxx-commits] [libcxx] [libc++][modules] Mark as implemented. (PR #90091)
Louis Dionne via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Apr 30 11:39:04 PDT 2024
ldionne wrote:
> IMO in general we document what we do not what vendors do. For example, we mark features as implemented even when Apple decides not to make them available on backdeployment targets. (I understand why Apple does not want to do that.).
Just to clarify, Apple doesn't "make features unavailable on backdeployment targets". It's simply that new features that require dylib support can't work on older targets that don't have said support and we happen to care enough about users to have the availability machinery to let users know at compile-time (instead of crashing at load-time). Any system that uses shared libraries and ships libc++ as part of the operating system would experience exactly the same limitations. Just clarifying for readers cause your initial statement made it look a bit like Apple deliberately made things unsupported on older platforms, which is not true and would be a questionable practice.
>
> So I'm happy to change that, but IMO then we should discuss what we consider as implemented and when we can mark things as implemented.
I think this is a bit different though: this setting was basically an "experimental" feature disabled by default and only existing for development purposes until now. But in LLVM 19, we are comfortable with getting this used a bit more widely, and so we can enable the CMake installation of modules by default, and ping vendors to let them know. Then we're giving them the choice of either shipping modules or not. But I think it's difficult to argue that we considered C++20 modules as implemented in LLVM 18 given the (lack of) communication we did about it, and how hidden we kept the setting.
https://github.com/llvm/llvm-project/pull/90091
More information about the libcxx-commits
mailing list