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.

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

Dismantle requirements table in [re.req] and [container.requirements] #4460

Merged
merged 4 commits into from Feb 3, 2022

Conversation

jensmaurer
Copy link
Member

@jensmaurer jensmaurer commented Jan 7, 2021

We've wanted to get rid of the huge requirement tables since ages. Here's a specific suggestion, converting [re.req] as a guinea pig. Note that this is a fairly mechanical conversion, avoiding larger rephrasing.

Fixes #120.
Fixes #4785
Fixes #78
Fixes cplusplus/papers#1086
Partially addresses #1571.

regex

@Eelis
Copy link
Contributor

Eelis commented Jan 9, 2021

Getting rid of the huge requirements tables would be great!

One small Q: is "return type" really appropriate for something like X::char_type? A quick search for "return type" in the spec suggests that so far, outside these requirements tables it's been used exclusively to refer to the return types of actual functions.

"Effects" also sounds kinda weird when describing compile-time type expressions that have no side-effects.

@jensmaurer
Copy link
Member Author

One small Q: is "return type" really appropriate for something like X::char_type?

No, but it's used like that pervasively in the requirements tables. I'd be happy fold this into a generic "Requirements" element or so. In general, those requirement tables are not abundantly clear whether a member is a type or an expression, anyway. (For example, X::size_type could be a static data member.)

@jensmaurer
Copy link
Member Author

Updated with @tkoeppe; samples:

reqtab-type-stmt

reqtab-expr

@tkoeppe
Copy link
Contributor

tkoeppe commented Apr 30, 2021

LWG supports this. Next step: turn this into a paper.

@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Apr 30, 2021
@jensmaurer
Copy link
Member Author

Editorial meeting 2021-04-30: "is an expression with the following properties:" Otherwise, good to go. Make a paper with containers and regex tables converted.

@jensmaurer jensmaurer added the changes requested Changes to the wording or approach have been requested and not yet applied. label Apr 30, 2021
@wg21bot wg21bot added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Jun 15, 2021
@jensmaurer jensmaurer removed the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Jun 16, 2021
@jensmaurer jensmaurer removed the changes requested Changes to the wording or approach have been requested and not yet applied. label Jun 17, 2021
@jensmaurer
Copy link
Member Author

use

X u = X();
X u;

drop presenting X(a,b,c) (it does not introduce "u") otherwise

@jensmaurer
Copy link
Member Author

@jwakely, Daniel Krügler has opined on the -lib reflector that "Result:" is an undefined descriptive item and that it would be better to use "Return type:" (which is similarly undefined, but at least pre-existing). However, an expression usually has a type and a value category, but not really a "return type". LWG3166 Should I just invent some words for "Result" for [structure.specification], or what would be your preferred way forward?

http://lists.isocpp.org/lib/2021/12/21327.php

@jwakely
Copy link
Member

jwakely commented Dec 6, 2021

I think it would be better to use Result: (and define it) rather than try to reuse something that isn't a great fit.

@Dani-Hub
Copy link
Member

Dani-Hub commented Dec 7, 2021

I think it would be better to use Result: (and define it) rather than try to reuse something that isn't a great fit.

I'm OK with that but would like to ask for explicitly referring to LWG 3166 as part of the paper.

@jensmaurer
Copy link
Member Author

I've added an entry for "Result:"to [structure.specification]. I think I'm not using "Value:" anywhere, so I'm not seeing why a reference to LWG3166 is necessary.

@Dani-Hub
Copy link
Member

I've added an entry for "Result:"to [structure.specification]. I think I'm not using "Value:" anywhere, so I'm not seeing why a reference to LWG3166 is necessary.

The new entry for "Result:" is new information to me, it was not present in the draft I had reviewed and where my request came from. Given the new state I agree that quoting LWG 3166 is no longer useful.

@jensmaurer
Copy link
Member Author

The new entry for "Result:" is new information to me, it was not present in the draft I had reviewed

Right, I've just added it.

@wg21bot wg21bot added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Jan 19, 2022
@jensmaurer jensmaurer removed the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Jan 19, 2022
@wg21bot wg21bot added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Jan 23, 2022
@jensmaurer jensmaurer removed the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Jan 23, 2022
and adjust cross-references to container requirements tables
throughout the standard library.
where "Effects: Equivalent to" wording is used.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lwg Issue must be reviewed by LWG.
Projects
None yet
7 participants