Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

[SUGGESTION] sizeof<T> vs sizeof(T) and sizeof(expr) #582

Closed
ntrel opened this issue Aug 12, 2023 · 1 comment
Closed

[SUGGESTION] sizeof<T> vs sizeof(T) and sizeof(expr) #582

ntrel opened this issue Aug 12, 2023 · 1 comment

Comments

@ntrel
Copy link
Contributor

ntrel commented Aug 12, 2023

  • Please do not suggest syntax changes. I accept there are hundreds of opinions and everyone will prefer something a little different. Syntax isn't the big thing, fixing semantics is -- reducing concept count, increasing toolability, are the big payoff.

This is about consistent concepts rather than just syntax.

From #574 (comment) Herb said:

I didn't see a reason to change from the familiar function-like syntax sizeof(thing) to sizeof ...? I was thinking of sizeof as a constexpr function for which ( ) would be fine.

AFAIU, a constexpr function can't take a type as an argument. E.g. you couldn't implement a function sizeof that can be called like sizeof(int). So I think sizeof<T> is more consistent. Are type parameters ever passed using function call syntax anywhere in cpp2?

Obviously, cpp1 sizeof also takes an expression. I think often this is just a shortcut to having to write sizeof(decltype(expr)). If that is the only reason, I would suggest it would be simpler not to have the expression parameter form at all and require using decltype for that.

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?

No.

Will your feature suggestion automate or eliminate X% of current C++ guidance literature?

It is simpler and more consistent, though it probably doesn't impact teaching much.

Describe alternatives you've considered.
There's nearly always more than one way to improve something. What other options did you consider? Why is the one you're suggesting better than those?

Sticking with cpp1 syntax is workable.

@JohelEGP
Copy link
Contributor

See also #531 (comment),
where Herb shows his intention to distinguish expressions and types as template arguments.
Unlike Cpp1, where the x in f<x> could be an expression or a type.

Repository owner locked and limited conversation to collaborators Aug 13, 2023
@hsutter hsutter converted this issue into discussion #586 Aug 13, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

2 participants