Heyo.

I have a struct with a couple "property" methods, like:

    struct A
    {
        auto foo(int bar) { /* do something */ }
    }

Is there any reason for me to add the @property tags for the method? The following code compiles just fine with the struct above

    A a = A();
    a.foo = 42; // no @property tag for `foo(int bar);` yet works

Best regards,
Vladimirs Nordholm

On Monday, 2 April 2018 at 13:57:14 UTC, Vladimirs Nordholm wrote:
> Is there any reason for me to add the @property tags for the method?

A list of things the @property tag does can be found here:
https://dlang.org/spec/function.html#property-functions

This behavior is particularly useful for generic code:
"For the expression typeof(exp) where exp is an @property function, the type is the return type of the function, rather than the type of the function."

Before I knew about this, I wrote this template to get the type of 'field', because typeof(field) would return 'int()' instead of 'int' when it was a getter function without @property.

```
template ReturnOrValueType(type)
{
	static if (isSomeFunction!(type.field)) {
		alias ReturnOrValueType = ReturnType!(typeof(type.field));
	}
	else {
		alias ReturnOrValueType = typeof(type.field);
	}
}
```

On Monday, 2 April 2018 at 14:20:49 UTC, Dennis wrote:
> On Monday, 2 April 2018 at 13:57:14 UTC, Vladimirs Nordholm wrote:
>> Is there any reason for me to add the @property tags for the method?
>
> A list of things the @property tag does can be found here:
> https://dlang.org/spec/function.html#property-functions
>
> This behavior is particularly useful for generic code:
> "For the expression typeof(exp) where exp is an @property function, the type is the return type of the function, rather than the type of the function."
>
> Before I knew about this, I wrote this template to get the type of 'field', because typeof(field) would return 'int()' instead of 'int' when it was a getter function without @property.
>
> ```
> template ReturnOrValueType(type)
> {
> 	static if (isSomeFunction!(type.field)) {
> 		alias ReturnOrValueType = ReturnType!(typeof(type.field));
> 	}
> 	else {
> 		alias ReturnOrValueType = typeof(type.field);
> 	}
> }
> ```

Ah! First time I read the docs I didn't understand the typeof(exp) explanation, but yours made me understand that part.

Do you think I should I omit the @property tag, if the only wanted behaviour is to set a value (`foo.bar = "baz";`) ?

On Monday, 2 April 2018 at 14:51:57 UTC, Vladimirs Nordholm wrote:
> On Monday, 2 April 2018 at 14:20:49 UTC, Dennis wrote:
>> On Monday, 2 April 2018 at 13:57:14 UTC, Vladimirs Nordholm wrote:
>>> Is there any reason for me to add the @property tags for the method?
>>
>> A list of things the @property tag does can be found here:
>> https://dlang.org/spec/function.html#property-functions
>>
>> This behavior is particularly useful for generic code:
>> "For the expression typeof(exp) where exp is an @property function, the type is the return type of the function, rather than the type of the function."
>>
>> Before I knew about this, I wrote this template to get the type of 'field', because typeof(field) would return 'int()' instead of 'int' when it was a getter function without @property.
>>
>> ```
>> template ReturnOrValueType(type)
>> {
>> 	static if (isSomeFunction!(type.field)) {
>> 		alias ReturnOrValueType = ReturnType!(typeof(type.field));
>> 	}
>> 	else {
>> 		alias ReturnOrValueType = typeof(type.field);
>> 	}
>> }
>> ```
>
> Ah! First time I read the docs I didn't understand the typeof(exp) explanation, but yours made me understand that part.
>
> Do you think I should I omit the @property tag, if the only wanted behaviour is to set a value (`foo.bar = "baz";`) ?

Yes I would omit @proporty if you don't need it as it isn't really useful at the moment.
There's a DIP to fix it and make it more powerful though:

https://github.com/dlang/DIPs/pull/97

And if you are looking for @read, @write limitations the accessors library might be interesting to you:

https://code.dlang.org/packages/accessors

On Monday, 2 April 2018 at 14:51:57 UTC, Vladimirs Nordholm wrote:
> Do you think I should I omit the @property tag, if the only wanted behaviour is to set a value (`foo.bar = "baz";`) ?

You're probably fine either way, it's mostly for making your intention clear. Jonathan M Davis made a great explanation:
(https://forum.dlang.org/post/mailman.709.1481234980.9448.digitalmars-d-learn@puremagic.com)

On Monday, 2 April 2018 at 15:05:04 UTC, Seb wrote:
> On Monday, 2 April 2018 at 14:51:57 UTC, Vladimirs Nordholm wrote:
>> On Monday, 2 April 2018 at 14:20:49 UTC, Dennis wrote:
>>> [...]
>>
>> Ah! First time I read the docs I didn't understand the typeof(exp) explanation, but yours made me understand that part.
>>
>> Do you think I should I omit the @property tag, if the only wanted behaviour is to set a value (`foo.bar = "baz";`) ?
>
> Yes I would omit @proporty if you don't need it as it isn't really useful at the moment.
> There's a DIP to fix it and make it more powerful though:
>
> https://github.com/dlang/DIPs/pull/97
>
> And if you are looking for @read, @write limitations the accessors library might be interesting to you:
>
> https://code.dlang.org/packages/accessors

Nice read, and the library seems interesting 👍

On Monday, 2 April 2018 at 15:15:05 UTC, Dennis wrote:
> On Monday, 2 April 2018 at 14:51:57 UTC, Vladimirs Nordholm wrote:
>> Do you think I should I omit the @property tag, if the only wanted behaviour is to set a value (`foo.bar = "baz";`) ?
>
> You're probably fine either way, it's mostly for making your intention clear. Jonathan M Davis made a great explanation:
> (https://forum.dlang.org/post/mailman.709.1481234980.9448.digitalmars-d-learn@puremagic.com)

His reasoning is the same as mine. I only have the @property as documentation :)