Clarification on @property functions

[Bolpat]

This question on stackoverflow and my personal struggling with the sentence suggests to add clarification.
I've done some tests with static member functions.

@property bool parity(int x) { return x & 1; }
@property void parity(ref int x, bool p) { (x |= 1) &= p; }

work well. For static member functions like these

struct Test
{
  static:
    @property bool parity(int x) { return x & 1; }
    @property void parity(ref int x, bool p) { (x |= 1) &= p; }
    
    void test()
    {
        int x = 1;
        bool p = parity(x); // (1)
        int y = 2;
        parity(y, p); // (2)
    }
}

the @property has no effect: Replace (1) and (2) by bool p = x.parity; and y.parity = p; respectively, you get the error no property 'parity' for type 'int'.

I don't know if this is intensional or a bug.

[dlang-bot]

Thanks for your pull request, @Bolpat! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.

Some tips to help speed things up:

• smaller, focused PRs are easier to review than big ones

• try not to mix up refactoring or style changes with bug fixes or feature enhancements

• provide helpful commit messages explaining the rationale behind each change

Bear in mind that large or tricky changes may require multiple rounds of review and revision.

Please see CONTRIBUTING.md for more information.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[jmdavis]

What does static have to do with anything? Whether the member function is static or not, if it's a getter or a setter that returns by ref, it has no parameters, and if it's a setter that does not return by ref it has one parameter. If it's a free function, then a getter has zero parameters and is used by itself, or it has one parameter and is used with UFCS, and if it's a setter, then it either has one parameter if it's used without UFCS and two if it's used with UFCS. static has no effect on any of this.

See @jmdavis's comment

[jmdavis]

Okay. You clearly don't understand how @property works with a static function. It has to use either the name of the struct/class with the @property function or use an instance. e.g. std.datetime.date.Date has Date.max.

Neither bool p = x.parity; nor y.parity = p; is attempting to call a static function. In order to call the static functions on Test, you'd need Test - e.g. Test.parity or Test.parity = something. I suppose that the bool overload of parity could work as a setter that returned bool, as bizarre as that would be, but neither works as a getter, and the other overload is not a valid @property function, because it has too many parameters.

I don't think that there's anything wrong with what the spec currently says. It's just that it doesn't necessarily go into enough detail. If we wanted to make it clearer, we'd probably need to provide examples of non-static member functions, member functions, and free functions with getters, setters, and functions that return by ref so that they're both getters and setters. I don't think that adjusting this particular piece of text is really going to do much by itself.

[jmdavis]

The other issue here is that none of this really has much to do with @property, in spite of the fact that it was originally supposed to. All of these rules with regards to the number of parameters and whatnot relate to whether a function can be called as a property function (which does not require @property), and the compiler clearly does not consider it an error to mark a function with @property when it can't be used as a property. AFAIK, all @property really does at this point is make it so that you can't overload the function with another function that isn't marked with @property and affect the type of is(foo.propFunc) so that if it's a getter property, the result is the return type and not the type of the function (I'm not sure what it does with a setter property). So, this whole section of the spec should probably be rewritten.