Description
Originating comment: #5713 (comment).
The paper has the following instructions:
Change in [memory.syn]
Instructions to the editor:
Please append a// freestanding
comment to the following entities:[...] allocation_result [...]
Change in [ranges.syn]
Drafting note:
[...]
Instructions to the editor:
Please append a// freestanding
comment to every entity in<ranges>
except for the following entities:basic_istream_view istream_view wistream_view views::istream
#5713 correctly follows these instructions. The resulting inconsistency can be gleamed from the resulting wording. In <memory>
, // freestanding
was appended to allocation_result
:
template<class Pointer>
- struct allocation_result {
+ struct allocation_result { // freestanding
Pointer ptr;
size_t count;
};
In <ranges>
, // freestanding
was appended to all instructed entities. Here's an extract:
template<class I, class S, ranges::subrange_kind K>
- struct tuple_element<1, const ranges::subrange<I, S, K>> {
- using type = S;
+ struct tuple_element<1, const ranges::subrange<I, S, K>> { // freestanding
+ using type = S; // freestanding
};
The inconsistency here is whether a class member (which is an entity) is appended // freestanding
.
3 # An entity is a value, object, reference, structured binding, function, enumerator, type, class member, bit-field, template, template specialization, namespace, or pack.
Activity
JohelEGP commentedon Nov 7, 2022
Option D of LWG3815 would address this by making those members currently marked
// freestanding
redundant.New issue from Ben Graig: "Freestanding enumerators specification is …
JohelEGP commentedon Apr 1, 2023
As mentioned in LWG3815, LWG3753 solved this. Those
// freestanding
comments for members can go.// freestanding
marks for freestanding class members #6430