• Quirin Schroll (46/46) Jul 18 D’s properties have issues.
• monkyyy (24/25) Jul 18 ?
• monkyyy (9/11) Jul 18 or simplier, @property adds in a unittest `static
• ryuukk_ (3/3) Jul 19 Please no, don't turn D into C#, there are lot of good ideas, put
• ryuukk_ (4/4) Jul 19 I now understand why you wanted @flags for enums, instead of
• harakim (3/8) Jul 20 What problems are you trying to solve? I have a lot of thoughts
• IchorDev (7/9) Jul 20 The way I see `@property` used (and the way I use it also) is to
• harakim (33/39) Jul 20 I like seeing all the DIP ideas. They make me think.

Quirin Schroll <qs.il.paperinik gmail.com> writes:

D’s properties have issues.

The basic idea for this DIP would be to add properties as a new 
kind of entity. A property would not be a function as far as the 
language is concerned. Asking the type of a property is 
meaningful.

A property, essentially, would be a getter–setter pair. It can’t 
be overloaded. The address of a property yields a property 
pointer or a property delegate, depending if the property is a 
non-static member property or not, similar to function pointers 
versus delegates.

A property pointer is a pair of function pointers, one pointing 
to the getter function and the other to the setter function.

A property delegate is a context pointer plus a property pointer, 
three pointers total.

A getter-only property is basically a function. Taking its 
address returns a function pointer or a delegate.



which I would allow.

Example:
```d
struct S
{
     size_t property length { get => 0; set { } }

     int property prop(string arg)
     {
         get => 0;
         set(int value) { /* use arg and value */ }
     }
}

S s;

cast(void)cast(size_t)s.length; // calls getter
cast(void)cast(size_t)s.length(); // error, parens not allowed
s.length = 10; // calls setter
s.length() = 10; // error, parens not allowed

s.prop("abc"); // calls getter
s.prop("abc") = 10; // calls setter

int property delegate() pdg1 = &s.length;
auto l = pdg1(); // indirect getter call
pdg1() = 0; // indirect setter call

int property delegate(string) pdg2 = &s.prop;
auto x = pdg2("abc"); // indirect getter call
pdg2("abc") = 10; // indirect setter call
```
As with function pointers and delegate, calls require parens, 
even if empty.

monkyyy <crazymonkyyy gmail.com> writes:

On Thursday, 18 July 2024 at 20:31:31 UTC, Quirin Schroll wrote:
 very new syntax

?

What if  property enforced that (when used), the length of the 
overload set is >2

```d

int foo()=>3;
void bar(int){};

alias foobar  property =foo;
alias foobar=bar;

unittest{
   int a=foo;//finds that foobar is an overload set with length 2,
   bar=a;
}
```

```d
struct foo{
    property int bar()=>3;
   void bar()(){ static assert(0);}
}
unittest{
   foo f;
   int=f.bar;//fails, while it detects bar(2), it fails some test
}
```

monkyyy <crazymonkyyy gmail.com> writes:

On Thursday, 18 July 2024 at 23:40:39 UTC, monkyyy wrote:
 
 

or simplier,  property adds in a unittest `static 
assert(__traits(compiles,foo=foo;))`

```d
 property int foo()=>3;
void foo(int){}//compiles

 property float bar()=>3;
void bar(float){}// fails "property bar can not assign to itself"
```

ryuukk_ <ryuukk.dev gmail.com> writes:

properties are not

I already hate the fact that parenthesis are optional in functions

ryuukk_ <ryuukk.dev gmail.com> writes:

I now understand why you wanted  flags for enums, instead of 
suggesting proper bitflags support, this is what happens when you 
take inspiration from a old language that is a copy of Java built 
with old mistakes

harakim <harakim gmail.com> writes:

On Thursday, 18 July 2024 at 20:31:31 UTC, Quirin Schroll wrote:
 D’s properties have issues.

 The basic idea for this DIP would be to add properties as a new 
 kind of entity. A property would not be a function as far as 
 the language is concerned. Asking the type of a property is 
 meaningful.

What problems are you trying to solve? I have a lot of thoughts 
on properties but I'm not seeing the improvement.

IchorDev <zxinsworld gmail.com> writes:

On Thursday, 18 July 2024 at 20:31:31 UTC, Quirin Schroll wrote:
 As with function pointers and delegate, calls require parens, 
 even if empty.

The way I see ` property` used (and the way I use it also) is to 
mark functions as being intended to be used like fields: `a.x`, 
`a.x = b`. This suggestion would break that meaning without 
functionally improving properties at all. I think the way 
properties work at the moment is better than the suggested 
functionality.

harakim <harakim gmail.com> writes:

On Saturday, 20 July 2024 at 17:05:57 UTC, IchorDev wrote:
 The way I see ` property` used (and the way I use it also) is 
 to mark functions as being intended to be used like fields: 
 `a.x`, `a.x = b`. This suggestion would break that meaning 
 without functionally improving properties at all. I think the 
 way properties work at the moment is better than the suggested 
 functionality.

I like seeing all the DIP ideas. They make me think.

On the subject at hand, I see a lot more property use at work 
than in D since I rarely see anyone else's D code. In my 
experience there are a few valid ways to use properties:
1. To auto-convert data that was serialized in another form. For 
example, you load an object from a database or file and it is a 
string, but you want to convert it to a date and time or 
expiration date or something custom. This is a valid use case. It 
can also be used for setting. It has no backing data.
2. To validate data before saving it to the object to enforce 
invariants. This has backing data and is valid as long as it 
doesn't mutate it.
3. Computing a property. For example, having an Age property but 
the backing data/field is a birthdate. This is get only and does 
not have any data of its own.
4. Providing a different access modifier for setters public 
DateTime BirthDate { get; private set; }. I question if this is 
worth a language feature.

Problematic or pointless ways to use properties:
1. Using it exactly like a field. public string Name { get; set; 
}. There is no point to this. It makes reflection slightly easier 
but otherwise it is a waste of a language feature.
2. Modifying the data on input. Even something like stripping 
whitepsace can often cause me to have to look through the code 
(b/c it is not matching on equals, for example) to figure out 
what is actually happening. That is not intuitive.


If I were to move in a direction it would be to support the valid 
cases and not support the invalid cases. D allows you to create 

but honestly that is probably preferable after my experience with 

make a standard to mark getters with pure or something like that.