pointers, functions, and uniform call syntax

Carl Sturtivant sturtivant at gmail.com
Mon Sep 3 19:10:39 PDT 2012


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.)



More information about the Digitalmars-d mailing list