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

[temp.deduct.type] Remove excessive spacing in example #6541

Merged
merged 1 commit into from Aug 31, 2023

Conversation

Eisenwave
Copy link
Contributor

@Eisenwave Eisenwave commented Aug 30, 2023

Firstly, the leading space in the parameter list of g1, g2, and g3 is obviously unintentional. This style isn't followed anywhere else in the example, and would be extremely unusual if intended.

Secondly, the spacing in f is quite excessive, and internally inconsistent with the remainder of the example. Just a few lines down, the example continues with:

template<bool E> void f1(void (*)() noexcept(E));
template<bool> struct A { };
template<bool B> void f2(void (*)(A<B>) noexcept(B));

So everywhere but f, the author has no problem using a very conservative amount of spacing for function pointers.

This inconsistency tells me that the current declaration of f is some in-dev version which only made it into the standard by accident.

@tkoeppe
Copy link
Contributor

tkoeppe commented Aug 30, 2023

obviously unintentional

In core wording, there is a deliberate absence of a preferred style, so I wouldn't be so certain that this is "obvious". As far as I understand, Core does not want to insinuate that there is one preferred way to write C++.

@Eisenwave
Copy link
Contributor Author

Eisenwave commented Aug 30, 2023

In core wording, there is a deliberate absence of a preferred style, so I wouldn't be so certain that this is "obvious". As far as I understand, Core does not want to insinuate that there is one preferred way to write C++.

I understand that, but realistically speaking:

int g1( int, float, float);

I doubt that putting a leading space only before the first parameter type in the function is intentional. To me this looks like an obvious stray space, since I yet have to meet a developer who writes code like this, and I doubt that clang-format can generate it.

There may not be a single canonical style in the standard, but I still believe that the surrounding code in the same example can be used to infer what the author's intended style is. If that intended style isn't being followed, then it's simply a mistake.

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.

Let's take that.

@jensmaurer jensmaurer merged commit 1339fdd into cplusplus:main Aug 31, 2023
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants