-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
Become C++20-compliant in our use of span #6251
Labels
Area-CodeHealth
Issues related to code cleanliness, linting, rules, warnings, errors, static analysis, etc.
Help Wanted
We encourage anyone to jump in on these.
Issue-Task
It's a feature request, but it doesn't really need a major design.
Priority-2
A description (P2)
Product-Conhost
For issues in the Console codebase
Product-Terminal
The new Windows Terminal.
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Comments
It's more likely that we'll just move to GSL 3 and become C++20-compliant in our use of |
I'll update this issue to reflect that then as a status tracker. Feel free to edit to add checkboxes if multiple issues need to be created that would tracked in this master issue. |
Thanks! 😄 |
DHowett
added a commit
that referenced
this issue
Jul 14, 2020
GSL 3, the next major version of GSL after the one we're using, replaced their local implementation of `span` with one that more closely mimics C++20's span. Unfortunately, that is a breaking change for all of GSL's consumers. This commit updates our use of span to comply with the new changes in GSL 3. Chief among those breaking changes is: * `span::at` no longer exists; I replaced many instances of `span::at` with `gsl::at(x)` * `span::size_type` has finally given up on `ptrdiff_t` and become `size_t` like all other containers While I was here, I also made the following mechanical replacements: * In some of our "early standardized" code, we used std::optional's `has_value` and `value` back-to-back. Each `value` incurs an additional presence test. * Change: `x.value().member` -> `x->member` (`optional::operator->` skips the presence test) * GSL 3 uses `size_t` for `size_type`. * Change: `gsl::narrow<size_t>(x.size())` -> `x.size()` * Change: `gsl::narrow<ptrdiff_t>(nonSpan.size())` -> `nonSpan.size()` during span construction I also replaced two instances of `x[x.size() - 1]` with `x.back()` and one instance of a manual array walk (for comparison) with a direct comparison. NOTE: Span comparison and `make_span` are not part of the C++20 span library. Fixes #6251
Merged
DHowett
added a commit
that referenced
this issue
Jul 14, 2020
GSL 3, the next major version of GSL after the one we're using, replaced their local implementation of `span` with one that more closely mimics C++20's span. Unfortunately, that is a breaking change for all of GSL's consumers. This commit updates our use of span to comply with the new changes in GSL 3. Chief among those breaking changes is: * `span::at` no longer exists; I replaced many instances of `span::at` with `gsl::at(x)` * `span::size_type` has finally given up on `ptrdiff_t` and become `size_t` like all other containers While I was here, I also made the following mechanical replacements: * In some of our "early standardized" code, we used std::optional's `has_value` and `value` back-to-back. Each `value` incurs an additional presence test. * Change: `x.value().member` -> `x->member` (`optional::operator->` skips the presence test) * GSL 3 uses `size_t` for `size_type`. * Change: `gsl::narrow<size_t>(x.size())` -> `x.size()` * Change: `gsl::narrow<ptrdiff_t>(nonSpan.size())` -> `nonSpan.size()` during span construction I also replaced two instances of `x[x.size() - 1]` with `x.back()` and one instance of a manual array walk (for comparison) with a direct comparison. NOTE: Span comparison and `make_span` are not part of the C++20 span library. Fixes #6251
ghost
pushed a commit
that referenced
this issue
Jul 14, 2020
GSL 3, the next major version of GSL after the one we're using, replaced their local implementation of `span` with one that more closely mimics C++20's span. Unfortunately, that is a breaking change for all of GSL's consumers. This commit updates our use of span to comply with the new changes in GSL 3. Chief among those breaking changes is: * `span::at` no longer exists; I replaced many instances of `span::at` with `gsl::at(x)` * `span::size_type` has finally given up on `ptrdiff_t` and become `size_t` like all other containers While I was here, I also made the following mechanical replacements: * In some of our "early standardized" code, we used std::optional's `has_value` and `value` back-to-back. Each `value` incurs an additional presence test. * Change: `x.value().member` -> `x->member` (`optional::operator->` skips the presence test) * Change: `x.value()` -> `*x` (as above) * GSL 3 uses `size_t` for `size_type`. * Change: `gsl::narrow<size_t>(x.size())` -> `x.size()` * Change: `gsl::narrow<ptrdiff_t>(nonSpan.size())` -> `nonSpan.size()` during span construction I also replaced two instances of `x[x.size() - 1]` with `x.back()` and one instance of a manual array walk (for comparison) with a direct comparison. NOTE: Span comparison and `make_span` are not part of the C++20 span library. Fixes #6251
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Area-CodeHealth
Issues related to code cleanliness, linting, rules, warnings, errors, static analysis, etc.
Help Wanted
We encourage anyone to jump in on these.
Issue-Task
It's a feature request, but it doesn't really need a major design.
Priority-2
A description (P2)
Product-Conhost
For issues in the Console codebase
Product-Terminal
The new Windows Terminal.
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
Description of the new feature/enhancement
After discussing with @DHowett about the issues with updating gsl due to gsl shifting to C++20 std:span behavior and in accordance with below, use of span will be updated to C++20 to minimize changes needed by the update.
A clear and concise description of what the problem is that the new feature would solve.
This will allow us to update gsl.
Proposed technical implementation details (optional)
The text was updated successfully, but these errors were encountered: