That is very nice. If you treat the star as a postfix operator, then even "->" is no longer needed:

   some_pointer*.field

`->` shouldn't be necessary to begin with... if the LHS is a pointer already, `.` could just auto-dereference it instead of generating an error like it does now.

Note that when you define smart pointer types C++ there is indeed a difference between `.` and `*` resp. `->`: the latter are typically overloaded to operate on the underlying pointer type whereas the former operates on the smart pointer class itself (e.g. calling `reset` on a `std::unique_ptr`). Not sure how you would do that with a single dereference operator.

It would have to have been designed to use external functions instead (eg spelled std::reset), which might even make the API more consistent since many accessor functions already require doing just that (eg std::begin)

Free functions like `std::begin` are meant for generic code. Apart from that, how would you even access the private members if the dot-operator was overloaded? (C++ does not support overloading the dot-operator for good reasons.)

Also with some function, perhaps even the existing one std::get<1>, like for some other existing types where the dot-operator is already broken. The special purpose field-access ability and the special-purpose dot syntax don’t have to the same exact operator, though I appreciate there were logical reasons for C++ to historically choose to combine them

I always wondered about that. Is there some technical reason that it was designed the way it was? Is it disambiguating something?

It seems like `.` could in theory be made to recursively dereference any number of layers down to the base type. It's not as though `.` has any other possible meaning when used directly against an address ... right?

Historical reasons: early C compilers didn't actually keep track of what the type of the LHS was, so they needed `.` vs `->` to properly disambiguate. Later C compilers did start tracking that, so the difference in syntax was no longer necessary, but stuck for reasons of history and backward compatibility

https://retrocomputing.stackexchange.com/questions/10812/why...

Besides the sibling comment, I believe many of the finer details of Chomsky's hierarchy wasn't understood at the time, language grammars were just sort of "home-grown".

But I might be wrong here.

It hasn't got anything to do with parsing algorithms, which is the closest connection between this topic and the Chomsky hierarchy.

Rather, it is due to the history of C. In the 1960s, a team in the UK (based at the University of Cambridge and the University of London) were developing a programming language called CPL–CPL was an evolution of ALGOL 60, by many accounts it suffered from the second system effect and was so complicated it is unclear if it was ever fully implemented. Like ALGOL, CPL had several different data types – integers, floating point, etc.

CPL was being developed using itself, to run on indigenous British mainframes (initially the EDSAC 2 and then Ferranti Atlas). In order to do so, they developed a simplified version of it, which came to be known as BCPL (for "Bootstrap CPL"). The designers of BCPL decided upon a rather radical simplification – only a single signed integer data type, with memory treated as one big array of that data type.

Martin Richards (of Cambridge) visited MIT in 1966, and brought BCPL with him to the US. (I think he may have actually been the first person to call it "BCPL"–prior to his visit to MIT, it wasn't really viewed as a language in its own right, just as a simplified form of CPL used as an implementation detail.) Richards wrote a BCPL implementation to run under CTSS on IBM 7094 mainframes.

At MIT, BCPL spread to the Multics project, who used it for various purposes – although they ended up choosing IBM's PL/I over BCPL as their main implementation language. From there, it in turn spread to MIT's Multics partners, GE (who sold their computing business to Honeywell in 1970) and Bell Labs.

At Bell Labs, Ken Thompson began working on his own programming language B, for DEC PDP minicomputers and GE/Honeywell mainframes. Thompson liked BCPL's semantics (the simplification of having only a single data type), but didn't like its syntax – hence, B was essentially BCPL with syntax changed to be more to Thompson's liking. Dennis Ritchie then joined Thompson in further developing B and porting it to more machines.

At some point, Ritchie began to view BCPL/B's "only one data type" approach as overly limiting, so he developed his own language, C – which started out as essentially B but with multiple data types added back in.

The thing was, early versions of C still relied heavily on BCPL/B's "everything is an int" philosophy. From what I understand, although variables could be declared to be something other than an int, at first the innards of expression compilation still assumed "int" was the only data type. So essentially, when the compiler went to compile "X.Y", by the time it processed the "." it had already forgotten what actual type X had and just saw it as an "int"

Later versions of C developed a more advanced type system, where less of BCPL/B's "everything is an int" philosophy survived. But there are still some remnants of it even in the latest C and C++ standards, in particular the "implicit promotion" rules.

You should probably just cast to an intermediary `struct foo *`. It'd be a lot more readable.