@property needed or not needed?

[Robert]

@property use:

I'd like to point out, that regardless of the "with parens/without
parens" stuff, marking properties with @property makes sense. So that
tools and frameworks can recognize them as such. This also implies that
fields that are meant as properties should be declared @property and the
compiler should generate getter/setter so it behaves exactly like a
manually created property. May I add this to DIP21?

Having the compiler lower the following:

@property int a;

to

private int __a;

@property int a() {
return __a;
}
@property int a(int new_a) {
  __a=new_a;
  return __a;
}

would make properties and property declared fields really exchangeable,
namely you can no longer take the reference of an @property field, just
like you can't take the address of a property with get/set.

Best regards,

Robert

On Sun, 2013-01-27 at 22:24 -0500, Steven Schveighoffer wrote:
> On Sat, 01 Dec 2012 20:03:21 -0500, Jonathan M Davis <jmdavisProg at gmx.com>  
> wrote:
> 
> > I'd _love_ to make it illegal to call non-property functions without  
> > parens,
> > and there are definitely folks around here who agree with me, including  
> > some on
> > the Phobos dev team (e.g. Steven has always agreed with me when this has  
> > come
> > up), but there are enough folks around here here who like to call  
> > functions
> > without parens - especially with UFCS and templated functions like map or
> > filter - that I don't think that that's going to fly at this point.
> 
> Oh, shit.  I missed another important @property discussion.
> 
> OK, I will say my peace:
> 
> The issue I have with not implementing this is takes power away from the  
> designer.
> 
> There are three intentions when creating a function w/ regards to  
> properties:
> 
> 1. You intend the function to be called without parentheses to clarify it  
> is a property.
> 2. You intend the function to be only called with parentheses to clarify  
> it is a function.
> 3. You don't care whether it's called with parentheses or not, because the  
> name of the function is clearly a property or a function.
> 
> These distinctions are important because of the human meaning of the  
> function.  i.e. x.read() vs. x.read.  The former looks to me like "read  
> using x", the latter looks like "is x read."
> 
> With @property, the idea was to implement 1 and 2, and leave nothing for  
> poor #3.  It's this #3 which throws a big fat wrench into my evil plans.   
> Things like map or filter, which clearly aren't properties by their  
> name/usage.
> 
> I had a compromise that void parameterless functions could be  
> unambiguously called without parentheses.  For example, if x.read()  
> doesn't return a value, then the statement:
> 
> x.read;
> 
> Can't really be misinterpreted as "is x read" because the code isn't using  
> the (implied) result.
> 
> So that is why I always thought, make non-property functions require  
> parentheses.
> 
> But here we are almost 4? years later and still have the same situation.   
> I give.  As long as we can't call arbitrary functions as setters, I think  
> the other failures of allowing the choice of removing parentheses are far  
> less severe.  At least we get #1.
> 
> The proposed DIP does not look bad, I say do it.
> 
> -Steve