Possible @property compromise

[Steven Schveighoffer]

On Tue, 29 Jan 2013 18:09:44 -0500, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Tuesday, January 29, 2013 12:10:04 Steven Schveighoffer wrote:
>> Sound crazy? Ridiculous? Impossible? Insulting?
>
> It seems like it could work, but without a way to explictly make  
> something a
> getter property, it will be impossible to change a property function  
> into a
> variable later without risking breaking code, because then people will  
> still
> be able to call the property function with parens. Using parens on getter
> properties has to be illegal for that to work.

I don't think this is quite right.

You can never *exactly* replace a field with a property, or vice versa.   
There are aspects that are different for both.

But there are two separate cases here.  One is, you define a property that  
is specific to a type, and then replace it with a field.  The other is  
that there is a DEFINED API, and you replace it with a field.

In the first case, yes, you would have to go through and replace ()  
instances with ones that do not have it.  If your documentation is clear,  
then it really is on the user to have made that mistake.  With the idea I  
specified later where getX would require no parentheses, you could specify  
a property that could not be called like a function unless you use the  
getX version.

But in the second case, consider for instance a range.  A range has an  
empty field/property.  If you called it via empty(), then your code is  
broken for all different types of ranges which use a field (or enum).

In any case, I think there is no getting around that changing from a  
property to a field or vice versa will cause problems for existing code.

-Steve