summaryrefslogtreecommitdiff
path: root/absl/types
diff options
context:
space:
mode:
authorGravatar Abseil Team <absl-team@google.com>2020-06-10 15:35:34 -0700
committerGravatar vslashg <gfalcon@google.com>2020-06-10 18:59:53 -0400
commite7ebf9803746b9a115d96164bdf5e915be8f223b (patch)
tree2ccafec5290edd068ee47751efb56f2eb51134b2 /absl/types
parent2eba343b51e0923cd3fb919a6abd6120590fc059 (diff)
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.h15
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