Taking address of properties

[Robert]

First of all, thanks for this very insight full discussion. I start to
understand the other side. :-)
On Fri, 2013-02-08 at 15:13 -0500, Steven Schveighoffer wrote:
> On Fri, 08 Feb 2013 14:05:40 -0500, Robert <jfanatiker at gmx.at> wrote:
> 
> > On Fri, 2013-02-08 at 12:52 -0500, Steven Schveighoffer wrote:
> >>
> >> Then it doesn't conform to the range API, where front is a property.
> > I can't find anything about that front has to be a property here:
> > http://dlang.org/phobos/std_range.html#isInputRange
> >
> > all it states that you can get the current element by issuing:
> > 	r.front
> > which would still be possible with the optional parentheses of DIP23.
> 
> Technically this is true.  But the expectation is that r.front is a  
> property/field, not a function.  That aspect is difficult to capture in a  
> template, especially in the current implementation where @property on a  
> getter is essentially redundant info.
In a template you should not care what it actually is, as long as this
works: 
	auto h=r.front;
(stolen from the implementation of isForwardRange), if I understood your
argument correctly.
> 
> In fact, the only case where a properly-implemented @property would be  
> required on a getter is for delegate properties.  I would argue that if  
> @property worked correctly, it would be possible and correct to require  
> r.front to be a property in that template.
I don't understand, what is the exact problem with: r.front()()? Despite
not matching the specification regarding no parentheses for properties?
> 
> Module level properties pose an issue, because @property does not  
> designate whether a property is a getter or a setter.  In particular, a  
> single-arg property function could be considered both a module property  
> setter, or a UFCS property getter.
> 
> So your issue is not really that UFCS properties are wrong, it's that  
> disabling module-level properties is wrong.  I agree with you, but at the  
> same time, module level properties are not as common or useful as UFCS.   
Sure UFCS for functions, I suggest that UFCS for properties does not
make a lot of sense. (If you apply my definition of a property and
accept simple functions with optional parentheses as better way.)

I am sorry, I don't understand what you mean here with:
> In fact, one could argue they are more confusing since module scope is one  
> of the only scopes that can be obscured.

> 
> There are other possible solutions, such as designating something as a  
> getter specifically, or adding more syntax (i.e. decorating the first  
> parameter as 'this' for a module-level UFCS getter).  But for now, the  
> easiest thing is to disallow one or the other, and since UFCS properties  
> are pretty much essential in Phobos, he's disabling the module level  
> properties.
> 
> The 42.fun = 43 example, just about everything is wrong with that.
> 
> Look here is another function that D "allows":
> 
> void increment(int x);
> 
> What is that exactly supposed to do?
> 
> 42.increment(); // what?
> increment(42); // what?
> 
> Design and naming of functions is never going to be a problem that the  
> compiler can solve.

Point taken. But my point is, that with optional parentheses UFCS
properties are not needed, so the cleaner solution is to forbid UFCS
properties. (See my DIP for further reasoning when it is ready)


> 
> My point on that was, if something works but is not supposed to, we  
> shouldn't have to worry about keeping that code working.  @property in its  
> current form is NOT implemented as it was designed.  There is no  
> requirement to keep existing behavior that doesn't correctly work.
> 
> In the example given, @property is supposed to ban the use of parentheses  
> according to the spec, but it doesn't.  In fact, in the case of a  
> @property that returns a delegate, it REQUIRES the extra parentheses.   
> This is a bug, and not something to try and keep working.
Despite being inconsistent with the specification, what are the problems
with that? 
> 
> On the other hand, ref @properties is NOT a bug, it functions as  
> designed.  Whether to remove it or not is certainly a discussion we can  
> have, but it's not buggy behavior.  See the difference?

But the documentation of properties: http://dlang.org/property.html
in the section about user defined properties also states in the very
first sentence:
	 Properties are functions that can be syntactically treated as 
	 if they were fields or variables.

which is clearly not true at the moment. If this sentence got removed
and replaced with a big fat warning that properties are not exchangeable
with fields, this would be the least that should be done.

The current thinking instead seems to be that properties are just
syntactic sugar and the level of encapsulation is business that is left
to the developer.

My thinking on the other hand is, that properties are the method of
encapsulation, so they should ensure it. If something does not, it is
not a property, which leads to a very clean design of properties.