Hello,
is there any advantage of marking function as @property??


class Foo {
    void objectValue(Object value) { }
    Object objectValue() { }
}



auto foo = new Foo;

// This works fine without @property attribute
foo.objectValue = null;
auto bar = foo.objectValue;

On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:
> is there any advantage of marking function as @property??

Not really. I think it just changes the meaning of typeof(thatfunc) but otherwise it does nothing.

However, if you use it in a base class, you must also use it when overriding the function.

On Thursday, December 08, 2016 16:54:57 Adam D. Ruppe via Digitalmars-d- learn wrote:
> On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:
> > is there any advantage of marking function as @property??
>
> Not really. I think it just changes the meaning of
> typeof(thatfunc) but otherwise it does nothing.
>
> However, if you use it in a base class, you must also use it when overriding the function.

Yeah, it's pretty common for folks to slap @property on functions to make it clear that it's intended to be used as a property and thus is a getter or setter. So, it serves a purpose from the standpoint of documentation. But at this point, it doesn't make much differently on the technical level. The differences with typeof and stuff like std.traits.FunctionAttributes are what would be different. You can use the property syntax whether @property was used or not.

The history of @property is a bit of a mess. It was an attempt to move away from the ad-hoc situation with anything being treated as a property if it had a signature that worked with one (e.g. something like writeln = 7; is legal), but for various reasons, it never worked out, and we got a partial transition with @property ultimately being mostly for documentation purposes.

One place where this is truly a technical problem rather than a stylistic one is property functions that return callables, since if you try and call them with parens, you end up just calling the property function (whether it's marked with @property or not), and you need a second set of parens to actually call the callable, meaning that it doesn't actually work as a property. So, @property _might_ be changed at some point in the future to fix that problem, but given how long it's been the way that it is, there's a good chance that we're just stuck with how it is, and it's going to do pretty much nothing on a technical level except cause some corner case weirdness with typeof and be detectable by introspection. It does serve as documentation though, which I think is a lot of why many folks who know full well what the whole situation with properties is continue to use it.

- Jonathan M Davis

On Thursday, 8 December 2016 at 16:54:57 UTC, Adam D. Ruppe wrote:
> On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:
>> is there any advantage of marking function as @property??
>
> Not really. I think it just changes the meaning of typeof(thatfunc) but otherwise it does nothing.
>
> However, if you use it in a base class, you must also use it when overriding the function.

it does when you add it to for example a struct with alias opCall this.
reported it as a bug
https://issues.dlang.org/show_bug.cgi?id=16951

but seems to be addressed by https://wiki.dlang.org/DIP23

On Thursday, December 08, 2016 22:11:22 ArturG via Digitalmars-d-learn wrote:
> On Thursday, 8 December 2016 at 16:54:57 UTC, Adam D. Ruppe wrote:
> > On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:
> >> is there any advantage of marking function as @property??
> >
> > Not really. I think it just changes the meaning of
> > typeof(thatfunc) but otherwise it does nothing.
> >
> > However, if you use it in a base class, you must also use it when overriding the function.
>
> it does when you add it to for example a struct with alias opCall
> this.
> reported it as a bug
> https://issues.dlang.org/show_bug.cgi?id=16951
>
> but seems to be addressed by https://wiki.dlang.org/DIP23

Except that it's not really a bug. It's a design flaw in the original solution for properties which gave us optional parens. And since @property has never really been implemented to properly _do_ much of anything, it doesn't actually fix the problem. While it's a nice idea in concept, @property was half-baked from the beginning, and it's never actually done anything useful except act as documentation. So, as it stands, @property doesn't matter for anything like this. It's just that we would need to actually implement something with it to solve that particular problem (DIP23 being one proposal to do so). And as it stands, property functions for callables simply don't work like a variable would, defeating the purpose of making them properties.

It would be very nice if we got a DIP that was approved which solved this, but @property is not a topic that much of anyone wants to discuss at this point. There's never really been agreement on how properties should be handled in D, and everyone is sick of discussing it. And we've lived with this flaw with callables and properties for years now. So, I think that it would be pretty hard to get a DIP past Walter and Andrei, much as we really should clean this @property mess up.

- Jonathan M Davis

On Thursday, 8 December 2016 at 22:46:32 UTC, Jonathan M Davis wrote:
> On Thursday, December 08, 2016 22:11:22 ArturG via Digitalmars-d-learn wrote:
>> On Thursday, 8 December 2016 at 16:54:57 UTC, Adam D. Ruppe wrote:
>> > On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:
>> >> is there any advantage of marking function as @property??
>> >
>> > Not really. I think it just changes the meaning of
>> > typeof(thatfunc) but otherwise it does nothing.
>> >
>> > However, if you use it in a base class, you must also use it when overriding the function.
>>
>> it does when you add it to for example a struct with alias opCall
>> this.
>> reported it as a bug
>> https://issues.dlang.org/show_bug.cgi?id=16951
>>
>> but seems to be addressed by https://wiki.dlang.org/DIP23
>
> ...
>
> - Jonathan M Davis

i actually didnt want to use @property at all, as i asumed that by using alias opCall this it would always call opCall not only sometimes.

the issue was about the commented line
// a; // Error: var has no effect in expression (a)

the rest can be solved by @property or a custom toString.

On Thursday, 8 December 2016 at 22:09:14 UTC, Jonathan M Davis wrote:
> On Thursday, December 08, 2016 16:54:57 Adam D. Ruppe via Digitalmars-d- learn wrote:
>> [...]
>
> Yeah, it's pretty common for folks to slap @property on functions to make it clear that it's intended to be used as a property and thus is a getter or setter. So, it serves a purpose from the standpoint of documentation. But at this point, it doesn't make much differently on the technical level. The differences with typeof and stuff like std.traits.FunctionAttributes are what would be different. You can use the property syntax whether @property was used or not.
>
> [...]


Thank you very much for your detailed explanation.

My issue isn't about @property, it just shows 3 cases where i think that dmd is missing a check for alias this.

Even if D didnt had @property or parentesis less function call,
due to alias opCall this it should be possible to call opCall without parentesis.