On Thursday, 25 August 2022 at 14:49:51 UTC, Salih Dincer wrote:
> On Thursday, 25 August 2022 at 13:23:25 UTC, bauss wrote:
>> Currently @property doesn't really do anything in this regard, so I imagine that the code would work the same without @property, no?
>
> One benefit of @property is that it allows the compiler to infer automatically.  So it behaves like auto but superior! For example:
>

That has nothing to do with @property, it works with @("") too.

On 8/28/22 6:36 PM, Steven Schveighoffer wrote:
> On 8/28/22 9:43 AM, Salih Dincer wrote:
>> On Thursday, 25 August 2022 at 03:49:07 UTC, Steven Schveighoffer wrote:
>>> It does just about nothing. The only discernable difference is `typeof`:
>>>
>>> ```d
>>> struct S
>>> {
>>>     int prop1() { return 1; }
>>>     @property int prop2() { return 2; }
>>> }
>>>
>>> pragma(msg, typeof(S.prop1)); // int()
>>> pragma(msg, typeof(S.prop2)); // int
>>> ```
>>
>> The function has parameters, the difference you're pointing isn't even visible :)
>> ```d
>> struct S
>> {
>>      int prop1(int a) { return a; }
>>      @property int prop2(int b) { return b; }
>> }
>>
>> pragma(msg, typeof(S.prop1(1))); // int
>> pragma(msg, typeof(S.prop2(2))); // int
>> ```
> 
> You are asking for the type of the expression which calls the function. (i.e. `typeof(s.prop2(1))` instead of `typeof(s.prop2)`. However, `typeof(s.prop2)` is going to fail, because the compiler is requiring property functions to be used when using `typeof` (and only when using `typeof`).
> 
> I'm trying to tell you this is the *only thing `@property` does*. In all other cases, it's indistinguishable from a normal function/method.

I think this should be immortalized and made very clear in the docs. It's an FAQ. (FWIW it's also a sign that the feature is not very helpful.)

One possibility to make it more useful would be to have @property disallow function signatures that cannot possibly be used as properties (e.g. multiple non-defaulted parameters).

Also properties that return UDTs by value are suspect because they lead to confusing code. Consider:

struct Widget { int a; }
@property Widget w() { return Widget.init; } // should be disallowed
void main() {
    w.a = 42; // does nothing, looks like it's assigning a value
}

Assigning values to fields of rvalues is a distinct long-standing problem.

On 25.08.22 15:18, Andrey Zherikov wrote:
> 
> I have no objections to deprecate `@property` attribute but I believe D must support the use case when `obj.mem` expression calls `obj.mem()` function (this is usually called property functions).

dmd.50 docs (2002):

--
All this is quite a bit of typing, and it tends to make code unreadable by filling it with getProperty() and setProperty() calls. In D, get'ers and set'ers take advantage of the idea that an lvalue is a set'er, and an rvalue is a get'er:
   class Abc
   {  int myprop;
      void property(int newproperty) { myprop = newproperty; } // set'er
      int property() { return myprop; }   // get'er
   }

which is used as:
   Abc a;
   a.property = 3;      // equivalent to a.property(3)
   int x = a.property;      // equivalent to int x = a.property()

Thus, in D you can treat a property like it was a simple field name. A property can start out actually being a simple field name, but if later if becomes necessary to make getting and setting it function calls, no code needs to be modified other than the class definition.
--

On Monday, 29 August 2022 at 08:40:51 UTC, Andrei Alexandrescu wrote:
>
> I think this should be immortalized and made very clear in the docs. It's an FAQ. (FWIW it's also a sign that the feature is not very helpful.)

So this is the state of @property:

- takes valuable time to discuss, over and over, for years
- serve no purpose other than "documentation", so it could be a phobos/druntime UDA
- it creeps up in code and PR, and each time needs an explanation

This is a net negative feature.

On 30/08/2022 2:45 AM, Guillaume Piolat wrote:
> On Monday, 29 August 2022 at 08:40:51 UTC, Andrei Alexandrescu wrote:
>>
>> I think this should be immortalized and made very clear in the docs. It's an FAQ. (FWIW it's also a sign that the feature is not very helpful.)
> 
> So this is the state of @property:
> 
> - takes valuable time to discuss, over and over, for years
> - serve no purpose other than "documentation", so it could be a phobos/druntime UDA
> - it creeps up in code and PR, and each time needs an explanation
> 
> This is a net negative feature.

It only does two things:

1. I can't remember the (single) semantic behavior
2. Create threads like this one

Time to go.