[phobos] Time to get ready for the next release

[Jonathan M Davis]

> > Allowing for @property functions to be called with parens or
> > non- at property
> > functions to be called without parens leads to major inconsistencies in
> > usage
> > of functions, and generally makes @property pointless. Even if you make
> > it so
> > that @property functions can't be called with parens while allowing non-
> > @property functions to be called without them, then that leads to
> > inconsistent
> > syntax for function calls and makes it harder to know whether something
> > is
> > actually a property function or not.
> 
> Why is this a benefit? Since your concept of a 'property' differs from
> mine, @property can only muddy the waters (unless we're both writing code
> using the same standards document). Being able to switch between call
> styles, allows me to self document my own (or my company's) guide-lines
> into the code. Besides, why should I care if something is a 'property'
> function or a regular function? or even a field, for that matter? There's
> field syntax and there's method syntax, but why should the library care
> how I choose to access their code? They don't have to read/review it. I
> (and my team/managers, etc) do.

One of the points of properties that I've seen commonly discussed in languages 
in general is the fact that you can more or less seemlessly switch between 
something being a public member variable and a property function. As soon as 
you're loose about enforcing property syntax that doesn't work. And the fact 
that D is loose about it is incredibly bizarre. It's the only language that I 
know of that works that way. Typically, property syntax is strictly enforced 
for property functions and completely disallowed for non-property functions. 
C# definitely works that way.

Property functions are part of the API of a library. The fact that they are 
property functions is part of that API, just like the names of functions and 
how many parameters they have is part of the API. So, making it so that 
@property is strictly enforced such that it strictly defines the syntax for 
calling a function isn't really any different from requiring that you use a 
specific name when calling a function. Making it loose instead is actually the 
sort of thing that is extremely uncommon in programming. Programming syntax is 
generally very exact.

What it sounds to me like is that you just don't like the idea of property 
functions and don't want to have to ever use them as property functions. 
Personally, I think that it is _way_ better than the incredibly lax way that 
property syntax has been handled in the past. And it seems perfectly normal to 
me that they'd be just as much a part of the API as the function's name. If 
@property isn't enforced, then I don't see much point in ever having added it 
in the first place. The only advantage that I can see with having @property 
and lax enforcement over no @property at all is the incredibly rare ambiguity 
with delegates, and I honestly don't think that that problem merits adding 
@property. Strictly enforcing @property, on the other hand, and making the 
syntax consistent _is_ well worth it.

- Jonathan M Davis