Bug 8161 – give an error for invalid property functions

This code compiles with -property: struct S { @property void prop() { } } void main() { } It makes no sense that it would. prop returns nothing, so it can't be used as a getter, and it takes nothing, so it can't be used as a setter. Neither S s; auto a = s.prop; nor s.prop = a; would compile, so there's no point in letting prop compile with @property. Another example would be a function like struct S { @property void prop(int a, int b) { } } It can't possibly be used as a property function either. I'd argue that any such function should be considered an error as long as it's marked as @property and the -property flag is used.

(In reply to comment #0) > This code compiles with -property: > > struct S > { > @property void prop() > { > } > } > > void main() > { > } > > > It makes no sense that it would. I can agree. > Another example would be a function like > > struct S > { > @property void prop(int a, int b) > { > } > } > > It can't possibly be used as a property function either. I'd argue that any > such function should be considered an error as long as it's marked as @property > and the -property flag is used. A @property function has two parameters is now allowed for UFCS property setter. @property foo(T)(T obj, int val) { ... } void main() { S s; s.foo = 1; // translated to .foo(s, 1), it's valid. }

> A @property function has two parameters is now allowed for UFCS property > setter. > @property foo(T)(T obj, int val) { ... } > void main() { > S s; > s.foo = 1; // translated to .foo(s, 1), it's valid. > } Yeah, because that's a free function. It's valid to use it as a property, so it makes sense for it to compile with @property. The example that I gave with two arguments was a member function, which already has the invisible this parameter, so it won't work as a property. The point is that any function which cannot be legally used as a property function should not compile when marked with @property and compiled with -property.

(In reply to comment #2) > > A @property function has two parameters is now allowed for UFCS property > > setter. > > > @property foo(T)(T obj, int val) { ... } > > void main() { > > S s; > > s.foo = 1; // translated to .foo(s, 1), it's valid. > > } > > Yeah, because that's a free function. It's valid to use it as a property, so it > makes sense for it to compile with @property. The example that I gave with two > arguments was a member function, which already has the invisible this > parameter, so it won't work as a property. > > The point is that any function which cannot be legally used as a property > function should not compile when marked with @property and compiled with > -property. OK. I got an understanding.

(In reply to Jonathan M Davis from comment #0) > struct S > { > @property void prop(int a, int b) > { > } > } > > It can't possibly be used as a property function either. I'd argue that any > such function should be considered an error as long as it's marked as > @property and the -property flag is used. This works: struct S { @property void prop(int a, int b){} } int main(string[] argv) { S s; s.prop = AliasSeq!(1, 2); return 0; } This behavior is not obvious though, and I agree that it should be disallowed.

> s.prop = AliasSeq!(1, 2); > I agree that it should be disallowed Yes, because otherwise the restriction to a maximum of 2 arguments doesn't make sense.

-property is dead, and anything revolving around changing what @property does (which is almost nothing) really needs a DIP.

Updated the title. Please give a reason why dmd shouldn't reject invalid @property functions.

(In reply to Nick Treleaven from comment #7) > Updated the title. Please give a reason why dmd shouldn't reject invalid > @property functions. The rules for using functions as properties currently have nothing to do with @property, and it's not clear that @property is even going to stay in the language. The plans for @property were dropped in that there are zero plans to enforce it (which includes the removal of -property), and it's not at all clear what's going to happen to it. It currently does very little, and adding any kind of enforcement to it at this point when it's not clear what (if anything) we're going to do with it really doesn't make sense. At this point, Walter and Andrei need to make a decision on what we're going to do with @property - be that on their own or as the result of a DIP. As it stands, @property does almost nothing. Off the top of my head, the list is: 1. It affects the result of typeof (the result is the type of the return value if @property is used, whereas it's the type of the function if @property isn't used). 2. It affects the mangling of the function (including affecting std.traits.functionAttributes). 3. It's not legal to overload a @property function with a non-@property function or vice versa. None of that involves enforcing that @property acts like a property function or that it is used as one, and none of it involves enforcing anything about non-@property functions. When UFCS was introduced, it became _extremely_ popular to leave off parens on function calls, and that killed any plans to enforce @property. That does not mean that we couldn't end up with some kind of enforcement that doesn't restrict what happens with non-@property functions, and maybe some kind of enforcement could be added to restrict the use of the assignment syntax to @property setters in order to make stuff like assigning to writeln illegal, but a DIP is required to sort all of that out, and as I understand it, at this point, Andrei and Walter consider @property to be a serious misstep. So, it really doesn't make sense to try and do anything to @property right now unless that involves writing a DIP with a full plan of what we're going to do with @property.

1. The text of this issue mentions -property, but I don't see why we shouldn't reject the cases it describes *regardless* of the -property switch. (This is why I removed the switch from the issue title). 2. This is about the *declaration* of nonsensical @property functions, it is not about optional parentheses in calls.

-property was dropped precisely because it was decided to not enforce @property, and the future of @property is very uncertain. The odds are very high that when Walter and Andrei finally get around to deciding what to do with @property that they will simply decide to deprecate it and remove it from the language. It makes no sense to add any kind of enforcement to something that's almost certainly going to be removed from the language. The fact that @property is even still used like it is is a combination of folks using it as documentation about what they intend to be used as a property and the fact that many folks mistakingly think that @property indicates which functions can be used as a property. Enforcing anything about @property at this point risks breaking existing code for something that we're probably not even keeping. If we're going to do anything with @property, it needs to be sorted out in a DIP that then gets official approval from Walter and Andrei. With a good enough argument, maybe they could be convinced to add some sort of enforcement to @property that doesn't affect non-@property functions, but without that, you're talking about potentially breaking code over something that's probably not even going to be staying in the language. That breakage could easily be worth it if we decide that @property is actually going to mean something, but the odds are much higher that it will be removed from the language than that it will be made to mean something useful.

I think @property could be useful in metaprogramming as a means of saying "This function acts like a field". Rather than going through all kinds of checks to see if the symbol was useable as such, it would suffice to check if it's @property, and then possibly which overloads are present to determine whether it's read/write/both. I think a good library implementation could do the same thing though: enum Accessibility { Read, Write, ReadWrite } template isUseableAsFieldOf(T, F, Accessibility access = Accessibility.Both)(F fun) {...} I would use something like that as a quick way to verify the target symbol of a serialization function.

I'd advise against relying on @property for any kind of metaprogramming at this point given that it doesn't actually have anything to do with whether the function can be or is used as a property and that its future in the language is uncertain. I don't think that there's any question that we _could_ do something more with @property, and it may yet be salvaged to do something useful related to properties, but whatever that may be really needs to be designed and then gotten past Walter and Andrei - and that means a DIP. Certainly, the idea that @property defines what can and can't be used as a property function is dead at this point.

(In reply to bitwise from comment #11) > enum Accessibility { Read, Write, ReadWrite } > > template isUseableAsFieldOf(T, F, Accessibility access = > Accessibility.Both)(F fun) {...} std.traits should provide this template irrespective of what happens to properties, because currently this idiom exists in the language, but not supported by reflection facilities.

> 1. It affects the result of typeof (the result is the type of the return value if @property is used, whereas it's the type of the function if @property isn't used). This alone makes it an important feature. > The odds are very high that when Walter and Andrei finally get around to deciding what to do with @property that they will simply decide to deprecate it and remove it from the language That would break much code significantly due to the above feature. AIUI there is no way the current language can simulate that feature. I remind you again that this issue has nothing to do with optional parenthesis.

(In reply to Nick Treleaven from comment #14) > This alone makes it an important feature. Actually, I think that it's caused more bugs than anything - especially when much is done with type introspection. Even though a property function tries to act like a variable, it isn't one and only marginally acts like one. Being able to call a function like a variable syntactically is useful, but semantically, it really isn't one, and having the symbol effectively lie about what it is makes writing good type introspection code harder (e.g. it made it harder to figure out a way to determine whether a member was a static variable or not when we originally tried to come up with how to implement hasStaticMember). As a systems language, it really isn't possible for a function to act completely like a variable, and having the function lie about it just because it's intended to partially emulate a variable does more harm than good IMHO - especially when it really has nothing to do with whether the function can be or is used with property syntax. > That would break much code significantly due to the above feature. AIUI > there is no way the current language can simulate that feature. > > I remind you again that this issue has nothing to do with optional > parenthesis. The point is that @property is considered a mistake by Walter and Andrei and is very much in limbo. What we have is a half-baked feature that does almost nothing and whose original design has clearly been abandoned. So, trying to "fix" it without there actually being an official decision about what we're going to do with it as a whole really doesn't make much sense - especially if that involves adding any compiler warnings or errors with regards to its use.

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