-
Notifications
You must be signed in to change notification settings - Fork 81
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
create std
module
#239
Comments
Do you mean by
the same as in #243? |
This is the link to the current Ranges proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0789r3.pdf You can look up there whether something will (likely) be included or not. |
I will try to explain this issue in more detail: Currently we rely heavily on the range-v3 library for providing lots of functionality. Most of the functionality will be part of C++20, but quite a few things will not, and some of the things will be, but under different names. To avoid code-duplication and similar-but-different function names et cetera we decided to rely only on those parts of range-v3 that will be part of C++20. Furthermore we would like to only have to depend on the range-v3 library if we cannot actually use C++20. This also means we need to find out which things won't be part of C++20 and implement those ourselves anyway (I call this To do this we decided to create an abstraction layer in the form of the
Anyway, it gets more difficult for things that have changed in C++20 ( |
So much for the general reasoning. As for why the range-v3 library and C++ have new versions of Let's illustrate this with an example. using std::begin;
auto it = begin(s); This tells the compiler to look for ¹ We are seeing exactly this for |
@h-2 Can you update the checkboxes? I think |
move to individual issues |
We will create a module called
std
that contains all wrapper and aliases of std and expected std functionality, i.e. implementations of standard library concepts and type_traits, as well as aliases for range-v3 functionality that is expected to be merged into the standard.Reason: this signals clearly to developers that something called
foo
and defined in that module is identical to suchfoo
in the standard library. It is also an indicator of "all this stuff is not biological, just infrastructure" and it also makes it easier to identify and remove the code in the distant future.Checklist
core/concept
therecore/metafunction
tostd/type_traits
<algorithm>
from range-v3In general I would propose:
ranges::
content must go through aliases in the std module.The text was updated successfully, but these errors were encountered: