Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Closed
JohelEGP opened this issue Aug 12, 2022 · 10 comments
Closed

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

JohelEGP opened this issue Aug 12, 2022 · 10 comments

Comments

@JohelEGP
Copy link
Contributor

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
Copy link
Contributor

CaseyCarter commented Aug 12, 2022 •
edited

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
Copy link
Contributor Author

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 JohelEGP mentioned this issue Aug 14, 2022
Merged
@JohelEGP
Copy link
Contributor Author

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
Copy link
Contributor

tkoeppe commented Aug 20, 2022

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

@jwakely
Copy link
Member

jwakely commented Aug 23, 2022

This will be LWG 3753.

@tkoeppe
Copy link
Contributor

tkoeppe commented Aug 23, 2022

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

@tkoeppe tkoeppe closed this as completed Aug 23, 2022
@JohelEGP
Copy link
Contributor Author

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

@tkoeppe
Copy link
Contributor

tkoeppe commented Aug 23, 2022

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

@JohelEGP
Copy link
Contributor Author

No, if there's no value to it.

@JohelEGP
Copy link
Contributor Author

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.

@JohelEGP JohelEGP mentioned this issue Sep 15, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@CaseyCarter @jwakely @tkoeppe @JohelEGP