https://issues.dlang.org/show_bug.cgi?id=8161

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unspecified                 |D2

--

https://issues.dlang.org/show_bug.cgi?id=8161

bitwise <nicolas.jinchereau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.jinchereau@gmail.co
                   |                            |m

--- Comment #4 from bitwise <nicolas.jinchereau@gmail.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=8161

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick@geany.org

--- Comment #5 from Nick Treleaven <nick@geany.org> ---
>     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.

--

https://issues.dlang.org/show_bug.cgi?id=8161

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
                URL|                            |https://github.com/dlang/dm
                   |                            |d/pull/8320

--

https://issues.dlang.org/show_bug.cgi?id=8161

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
-property is dead, and anything revolving around changing what @property does (which is almost nothing) really needs a DIP.

--

https://issues.dlang.org/show_bug.cgi?id=8161

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---
            Summary|-property should give an    |give an error for invalid
                   |error for invalid property  |property functions
                   |functions                   |

--- Comment #7 from Nick Treleaven <nick@geany.org> ---
Updated the title. Please give a reason why dmd shouldn't reject invalid @property functions.

--

https://issues.dlang.org/show_bug.cgi?id=8161

--- Comment #8 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=8161

--- Comment #9 from Nick Treleaven <nick@geany.org> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=8161

--- Comment #10 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
-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.

--

https://issues.dlang.org/show_bug.cgi?id=8161

--- Comment #11 from bitwise <nicolas.jinchereau@gmail.com> ---
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.

--