diff options
author | Abseil Team <absl-team@google.com> | 2020-06-10 15:35:34 -0700 |
---|---|---|
committer | vslashg <gfalcon@google.com> | 2020-06-10 18:59:53 -0400 |
commit | e7ebf9803746b9a115d96164bdf5e915be8f223b (patch) | |
tree | 2ccafec5290edd068ee47751efb56f2eb51134b2 /absl/types | |
parent | 2eba343b51e0923cd3fb919a6abd6120590fc059 (diff) | |
download | abseil-e7ebf9803746b9a115d96164bdf5e915be8f223b.tar.gz abseil-e7ebf9803746b9a115d96164bdf5e915be8f223b.tar.bz2 abseil-e7ebf9803746b9a115d96164bdf5e915be8f223b.zip |
Export of internal Abseil changes
--
44b312da54263fc7491b5f1e115e49e0c1e2dc10 by Greg Falcon <gfalcon@google.com>:
Import of CCTZ from GitHub.
PiperOrigin-RevId: 315782632
--
27618a3b195f75384ba44e9712ae0b0b7d85937e by Greg Falcon <gfalcon@google.com>:
Update Abseil's internal Invoke() implementation to follow C++17 semantics.
Starting in C++17, when invoke'ing a pointer-to-member, if the object representing the class is a reference_wrapper, that wrapper is unpacked. Because we implement a number of functional APIs that closely match C++ standard proposals, it is better if we follow the standard's notion of what "invoking" means.
This also makes `absl::base_internal::Invoke()` match `std::invoke()` in C++17. I intend to make this an alias in a follow-up CL.
PiperOrigin-RevId: 315750659
--
059519ea402cd55b1b716403bb680504c6ff5808 by Xiaoyi Zhang <zhangxy@google.com>:
Internal change
PiperOrigin-RevId: 315597064
--
5e2042c8520576b2508e2bfb1020a97c7db591da by Titus Winters <titus@google.com>:
Update notes on the delta between absl::Span vs. std::span.
PiperOrigin-RevId: 315518942
--
9d3875527b93124f5de5d6a1d575c42199fbf323 by Abseil Team <absl-team@google.com>:
Internal cleanup
PiperOrigin-RevId: 315497633
GitOrigin-RevId: 44b312da54263fc7491b5f1e115e49e0c1e2dc10
Change-Id: I24573f317c8388bd693c0fdab395a7dd419b33b0
Diffstat (limited to 'absl/types')
-rw-r--r-- | absl/types/span.h | 15 |
1 files changed, 5 insertions, 10 deletions
diff --git a/absl/types/span.h b/absl/types/span.h index 734db695..4e450fc9 100644 --- a/absl/types/span.h +++ b/absl/types/span.h @@ -27,22 +27,17 @@ // `Span<const T>` when such types may be difficult to identify due to issues // with implicit conversion. // -// The C++ standards committee currently has a proposal for a `std::span` type, -// (http://wg21.link/p0122), which is not yet part of the standard (though may -// become part of C++20). As of August 2017, the differences between -// `absl::Span` and this proposal are: -// * `absl::Span` uses `size_t` for `size_type` -// * `absl::Span` has no `operator()` -// * `absl::Span` has no constructors for `std::unique_ptr` or -// `std::shared_ptr` +// The C++20 draft standard includes a `std::span` type. As of June 2020, the +// differences between `absl::Span` and `std::span` are: +// * `absl::Span` has `operator==` (which is likely a design bug, +// per https://abseil.io/blog/20180531-regular-types) // * `absl::Span` has the factory functions `MakeSpan()` and // `MakeConstSpan()` -// * `absl::Span` has `front()` and `back()` methods // * bounds-checked access to `absl::Span` is accomplished with `at()` // * `absl::Span` has compiler-provided move and copy constructors and // assignment. This is due to them being specified as `constexpr`, but that // implies const in C++11. -// * `absl::Span` has no `element_type` or `index_type` typedefs +// * `absl::Span` has no `element_type` typedef // * A read-only `absl::Span<const T>` can be implicitly constructed from an // initializer list. // * `absl::Span` has no `bytes()`, `size_bytes()`, `as_bytes()`, or |