[ranges.syn] Should the *namespace-alias* `std::views` be `// freestanding`?

[JohelEGP]

Related comments: #5713 (comment) #5713 (comment)

https://wg21.link/p1642r11 defines

A freestanding entity is a declaration or macro definition that is present in a freestanding implementation and a hosted implementation.
[...]
In a header synopsis, entities followed with a comment that includes freestanding are freestanding entities.

Notably, a freestanding entity is not an entity:

3 # An entity is a value, object, reference, structured binding, function, enumerator, type, class member, bit-field, template, template specialization, namespace, or pack.

The paper has the following instructions:

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

The paper instructs to append // freestanding to entities in <ranges>, which excludes the namespace-alias std::views by definition.

I commented:

I suppose this begs the question, do freestanding implementations have to use std::ranges::views rather than std::views?
-- #5713 (comment)

Currently, by my fault, #5713 does append // freestanding to std::views, but that currently has no effects since std::views is not an entity.

[CaseyCarter]

The root cause here seems to be that [freestanding.entity]/3 uses "entities":

In a header synopsis, entities followed with a comment that includes freestanding are freestanding entities.

where it should instead say "declarations and macro definitions":

In a header synopsis, declarations and macro definitions followed with a comment that includes freestanding are freestanding entities.

As is fairly obvious from the following example that applies such a comment to a macro definition, which is not an entity.

I think we need an LWG issue to normatively fix [freestanding.entity]/3.

[JohelEGP]

I think we need an LWG issue to normatively fix [freestanding.entity]/3.

It's also necessary to clarify whether the paper's instructions to the editor that mention "every entity" actually meant "all declarations and macro definitions". std::views should be a freestanding entity.

[JohelEGP]

I think we need an LWG issue to normatively fix [freestanding.entity]/3.

It's also necessary to clarify whether the paper's instructions to the editor that mention "every entity" actually meant "all declarations and macro definitions". std::views should be a freestanding entity.

That'd also help clarify #5713 (comment). As per the literal instructions, class members of allocator_arg_t and more are appended // freestanding, but not those of allocation_result.

[tkoeppe]

@ben-craig: would you care to file an LWG issue for this?

[jwakely]

This will be LWG 3753.

[tkoeppe]

Thank you! I will close this editorial issue then, and see you in the next meeting's motions :-)

[JohelEGP]

Should this get a LWG label for consistency with issues with a CWG label being closed after a corresponding CWG issue is created?

[tkoeppe]

Since it's already closed, I really don't care, nor can I think of anyone who would. Do you?

[JohelEGP]

No, if there's no value to it.

[JohelEGP]

I think we need an LWG issue to normatively fix [freestanding.entity]/3.

It's also necessary to clarify whether the paper's instructions to the editor that mention "every entity" actually meant "all declarations and macro definitions". std::views should be a freestanding entity.

That'd also help clarify #5713 (comment). As per the literal instructions, class members of allocator_arg_t and more are appended // freestanding, but not those of allocation_result.

There are not handled by the LWG issue, though.