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 <jfanati...@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.