Bug 8162 – [TDPL] -property fails to give an error when a property function is called with parens

This code struct R42 { @property int front() @safe const pure nothrow { return 42; } @property bool empty() @safe const pure nothrow { return false; } void popFront() @safe pure nothrow { } } void main() { R42 r; auto e = r.empty(); } shouldn't compile, since empty is a property and therefore must not compile with parens per strict property enforcement as described in TDPL. _Not_ calling popFront with parens _does_ result in an error with -property, but calling either of the property functions _with_ parens doesn't. So -property seems to be doing half of its job but not all of it. With -property, @property functions should never be callable with parens, and non-@property functions should never be callable without them.

(In reply to comment #0) [snip] > shouldn't compile, since empty is a property and therefore must not compile > with parens per strict property enforcement as described in TDPL. _Not_ calling > popFront with parens _does_ result in an error with -property, but calling > either of the property functions _with_ parens doesn't. So -property seems to > be doing half of its job but not all of it. With -property, @property functions > should never be callable with parens, and non-@property functions should never > be callable without them. I can agree in basic, but I know a case which the strict property enforcement will cause problems. It is opDispatch. void main() { S s; assert(s.prop == 10); // s.prop is expected as property assert(s.func(1) == 2); // s.func is expected as member function } struct S { @property auto opDislatch(string name, A...)(A args) { static if (name == "prop" && A.length==0) return 10; static if (name == "func" && A.length==1) return args[0] * 2; } } If strict property enforcement is implemented, S.opDispatch won't work anymore. Because @property is not considered by overload resolution.

> If strict property enforcement is implemented, S.opDispatch won't work anymore. > Because @property is not considered by overload resolution. I believe that opDispatch already has the issue that you can't use property and non-property functions with it (IIRC someone on D.Learn was discussing that not too long ago). So, we probably need to do something special with opDispatch anyway. As it stands, strict property enforcement (as TDPL describes) doesn't work properly, and it should.

(In reply to comment #2) > As it stands, strict property enforcement (as TDPL describes) doesn't work > properly, and it should. And I think the more time we wait, the less easy it becomes to fix such problems.

(In reply to comment #1) > If strict property enforcement is implemented, S.opDispatch won't work anymore. > Because @property is not considered by overload resolution. This is already a problem; i had cases where i couldn't use opDispatch, because i needed both the @property and "method" versions... It would be best if both property and non-property versions would be legal at the same time, at least for opDispatch. This bug has more serious consequences -- think properties that return callables -- 'o.property()' does not do what you expect it to do, instead you have to work-around with 'o.property()()', which doesn't really make sense.

> This bug has more serious consequences -- think properties that return > callables -- 'o.property()' does not do what you expect it to do, instead you > have to work-around with 'o.property()()', which doesn't really make sense. That's one of the major reasons that @property was introduced - to disambiguate when returning delegates. So, the fact that -property doesn't help with that at all is a huge indicator that there's a major problem with it.

*** Issue 8372 has been marked as a duplicate of this issue. ***

*** Issue 7307 has been marked as a duplicate of this issue. ***

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18443 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB