I've noticed you italicized a lot of things relating to "understanding" how the language works. Many who do understand it feel the declaration syntax sucks inherited from C is a PITA. If only programmers were taught declaration syntax, they'd come across this and the intention would be clear:

int (*f(int x))[3]
{
// ...
}

Also, I think my argument is somewhat supported by:

using T = char*;
T a, b;

Yes, I understand the grammar, and yes, I understand how this is different vis-a-vis grammar, but I'm not arguing about the grammar, I'm arguing about what _style_ is more "C++-esque". Here, T is the type specifier with no pointer declarator. The _type_ is actually now `char*` So when declaring these two names, they have the same types. That's the more natural use case one would expect from a programming language. Clearly, this is a matter of taste, but again, I'll point out that Bjarne Stroustrup is clearly on my side of this disagreement. Here's a funny quote from one of the links I included in my first post: "The flip side of this is that you have to deal with old mistakes and with compatibility problems. For example, I consider the C declarator syntax an experiment that failed" From this interview: [Slashdot | Interviews | C++ Answers From Bjarne Stroustrup](http://www.stroustrup.com/slashdot\_interview.html)

* `char* c` is preferred for C++. See (1). * `char *a, *b, *c;` is sloppy - separate each declaration. See (2) * For those arguing that pointers are not types, I would say that this amounts to arguing semantics (syntax?) at best. The C++ Standard (3) frequently talks about pointers as types. Moreover, operators dealing with the type system, such as `typeid`, `decltype` deal with pointers as types. The entire _goal_ of smart pointers is to give types that can be transparently treated like pointers (along with additional behavior - object lifecycle mgmt., typically). Overloading, resolution, etc., all deal in "types" and pointers is part-and-parcel to this. * (Practical usefulness) The "right to left" reading gives the intuitive type of a name. This works better than the "whitespace association" model. Consider:

int* const volatile p1; // p1 is a volatile const pointer to an int
int *const volatile p2; // (*const volatile p2) is an int?

* I'm declaring the name `a` to be a pointer to a `MyObject`, I'm not declaring the `MyObject` itself, I'm just declaring the _pointer_. To the point of my second bullet above, `MyObject a, *b` is nasty, because for a C++ programmer, the first variable is declaring an object, the second is declaring just a pointer. If the context of this is declaring local/global variables, the `a` involves a (potentially non-trivial) constructor, which entails who knows what. `b` is simply telling the compiler to reserve some bytes for a pointer. (Something similar can be said where these are fields of a class/struct/union.) These are wildly different things in C++. 1. [Stroustrup: C++ Style and Technique FAQ](http://www.stroustrup.com/bs\_faq2.html#whitespace) 2. [CppCoreGuidelines/CppCoreGuidelines.md at master · isocpp/CppCoreGuidelines · GitHub](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-name-one) 3. [Working Draft, Standard for Programming Language C++](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf)

I can't think of an on-topic comment that uses "uranus". :(

It's almost certainly a matter of month/day being most often used, year being added on optionally. Consider the MM/DD portion of the date to be day-of-year. It's big-endian, which isn't bad in itself. Appending the year afterwards vs beforehand is normal in speech, but when you write it, it appears that you're now using little-endian: day-of-year/year. It's awkward, but not crazy. If you think that crazy because mixing little-endian with big-endian is crazy, consider that DD/MM/YYYY is already mixing little- with big-, since the actual digits we write are big-endian. (I prefer YYYY-MM-DD, myself, which is all big-endian and fully consistent, but the American way isn't illogical, per se.)

Jesse