Fixing const arrays

[Jonathan M Davis]

On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
> > On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
> >> Insisting on the current property semantics was a sizeable mistake of
> >> this community, and I am sorry we gave into it.
> > 
> > Aside from the fact that the behavior of -property isn't the default,
> > what's the problem with @property?
> 
> Other than it being completely useless, requiring more rote
> memorization, and fomenting time-wasting discussion? None.

So, you prefer the situation where any function with no arguments can be used 
as a getter and any function with a single argument can be used as a setter? 
Not only is that incredibly lax, but it makes it impossible to be able to 
switch between public member variables and property functions without breaking 
code, which is supposed to be one of the main purposes of property functions 
in programming languages in general. With @property, such a switch _is_ 
possible (aside from a few corner cases such as when someone takes the address 
of a public member variable). It will also lead to a consistent use of 
parentheses instead of having the syntax used with a function varying wherever 
it's used.

Sure, you then get arguments over whether a function should be a property or 
not, but that's generally just part of the discussion of how to name a 
function, and with that, there's always risk that someone will disagree later, 
so I'm not sure that it makes the situation all that much worse, and IMHO it's 
well worth the advantage of having proper properties. What D had was better 
than nothing, but it was inconsistent and lacked the ability to swap member 
variables and property functions, which made it far worse than @property IMHO.

- Jonathan M Davis