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

[memory.syn][specialized.algorithms] Prefer trailing returns on complex signatures #6964

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

AlisdairM
Copy link
Contributor

@AlisdairM AlisdairM commented May 7, 2024

This proposed change follows the observation that when function template signatures get complicated, especially with long names for return types, and non-trivial requires clauses, it can be very hard to spot the function name and return type among the sea of tokens, in order to start mentally parsing the function.

Here we propose using the trailing return type form of function declaration in those cases, and apply it consistently to the special algorithms in the <memory> header as a non-trivial sample size to gauge interest in a more complete PR that would cover the whole ranges library.

…ex signatures

This proposed change follows the observation that when function
template signatures get complicated, especially with long names
for return types, and non-trivial requires clauses, it can be
very hard to spot the function name and return type among the
sea of tokens, in order to start mentally parsing the function.

Here we propose using the trailing return type form of function
declaration in those cases, and apply it consistently to the
special algorithms in the '<memory>' header as a non-trivial
sample size to gauge interest in a more complete PR that would
cover the whole ranges library.
@AlisdairM AlisdairM force-pushed the trailing_return_for_constrained_templates branch from fd4d672 to 56fb956 Compare May 7, 2024 18:05
Copy link
Member

@jensmaurer jensmaurer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must say, I'm underimpressed. Some changes seem outright non-improvements, such as I f(...) -> auto f(...) -> I.

pair<ForwardIterator, NoThrowForwardIterator> seems to be the most complicated return type I can spot, and that doesn't feel overly complicated.

In any case, I want the opinion of LWG on a global change like that.
(If we feel the name of the function isn't sufficiently highlighted, maybe we can do something on the typographical level, e.g. make it bold.)

@jwakely ?

@jensmaurer jensmaurer added the lwg Issue must be reviewed by LWG. label May 7, 2024
@wg21bot wg21bot added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Dec 23, 2024
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. needs rebase The pull request needs a git rebase to resolve merge conflicts.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants