(cpp) Add additional keywords#2289
(cpp) Add additional keywords#2289joshgoebel merged 3 commits intohighlightjs:masterfrom aostrowski:patch-1
Conversation
| 'printf putchar puts scanf sinh sin snprintf sprintf sqrt sscanf strcat strchr strcmp ' + | ||
| 'strcpy strcspn strlen strncat strncmp strncpy strpbrk strrchr strspn strstr tanh tan ' + | ||
| 'vfprintf vprintf vsprintf endl initializer_list unique_ptr', | ||
| 'vfprintf vprintf vsprintf endl initializer_list unique_ptr _Bool complex _Complex _Imaginary', |
There was a problem hiding this comment.
Shouldn't we also have imaginary as well?
There was a problem hiding this comment.
Surprisingly, no. Those are keywords coming from C99, not all of them have their equivalents in the C++ standard library.
There was a problem hiding this comment.
I said that because of: https://en.cppreference.com/w/c/numeric/complex/imaginary
double imaginary i = 2.0*I; // pure imaginary
This macro expands to the keyword _Imaginary.
Defined in complex.h... if we don't count both how are we deciding that _Imaginary is a keyword but imaginary is not?
I'm welcome to be wrong here, but I'm trying to understand the logic we're using to call something a keyword.
There was a problem hiding this comment.
You didn't respond? Am I thinking about this wrong? ... ?
There was a problem hiding this comment.
double imaginary i = 2.0*I; // pure imaginary
double _Imaginary i = 2.0*I; // pure imaginary
Given this snippet, wouldn't both cases of imaginary there count as keywords? Yes/no? Or are we drawing a distinction between build-in vs pulled in via some include?
Complex seems to be in the same boat:
https://en.cppreference.com/w/c/language/arithmetic_types#Complex_floating_types
So it seems to me if complex is a keyword, then imaginary also should be, and if not, then it should not? Same for bool...
There was a problem hiding this comment.
I think if you just want to do the simplest thing to get this PR approved from where I'm setting it seems we need to add imaginary as a keyword also, and then we're consistent. But fell free to make a case the other way if you think that's not correct.
|
Also, please add a changelog entry. |
No description provided.