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

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

--

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

--- Comment #13 from anonymous4 <dfj1esp02@sneakemail.com> ---
(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.

--

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

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid

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

--

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

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

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

--