pointers, functions, and uniform call syntax

[Jonathan M Davis]

On Tuesday, September 04, 2012 00:49:48 Carl Sturtivant wrote:
> Thank you for your frankness. The above being the case, I wonder
> why p.frog where p is a pointer has been made to work when a
> wrapper will do the job. Is that something that might best be
> removed? It is after all an aesthetic matter.

You mean getting rid of the automatic pointer dereferencing, making you do 
(*p).frog instead of p.frog?

Well, regardless of the merits of one or the other, changing it would break 
code. The decisions for that were made ages ago. It doesn't merit revisiting 
at this point.

And it's not that aesthetics don't matter. It's that they matter very little 
in comparison to other things, and given that changing them breaks code and 
given where we are in D's development, making such changes doesn't generally 
make sense. They needed to have been decided when the language was much 
younger and still in flux. As it is, it's mostly frozen, and we're looking to 
achieve full stability so that people can count on their D code continuing to 
compile.

Changes which break code need a _really_ good reason to be made, and even if a 
change doesn't break code, we're not looking to complicate the language 
further if we don't need to. Also, the more things that get added, the less 
stable the compiler will be (at least in the short term) and the less work 
that gets put into fixing what we already have.

D is past the point where we're looking to actively work on and change its 
design. We want it to be stable and useable like you get with mainstream 
languages like C++ or Java (only with the benefits of D's features of course). 
Adding more features (even if they're backwards compatible) distracts from 
that, and making breaking feature changes goes completely against it.

I'm sure that once the compiler is more stable and all of the features that we 
already have work appropriately that we'll be more open to adding backwards 
compatible features (e.g. user-defined attributes). But this is just about the 
worst time in D's development to ask for features, because we're past the 
point of freezing the initial design but not yet stable enough to seriously 
consider adding additional, backwards-compatible features. So, new feature 
requests really need to pull their weight.

- Jonathan M Davis