On Monday, 3 September 2012 at 23:13:26 UTC, Jonathan M Davis
wrote:
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
Understood, and again thanks for speaking overtly and frankly
about this.
So in practical terms for this thread's issue, only the corner
case is relevant at this point, of whether '.' as a courtesy
might compile a call of bar(S s, int i) when p.bar(3) is written
and p is of type S* --- and if the usual struct pointer courtesy
for '.' is definitely in the language, then having this as well
does seem more uniform. I hope it goes through. (Plus it helps to
have somewhat reasonable explanations of what can and cannot be
done to supply to students of programming: uniform rules help.)
