@property Incorrectly Implemented?

[Ethan Watson via Digitalmars-d]

On Sunday, 11 September 2016 at 07:19:54 UTC, John wrote:
> You can't really take one sentence out of context, I didn't say 
> it in the sense that it was completely broken to the point of 
> being useless.

There's nothing out of context about it. Would it have made you 
feel better had I quoted your entire message knowing that I 
wouldn't have changed a word of the response?


But if that's how you want to play.

> The part I'm asking to be changed, you probably didn't even 
> ever use. C# is a managed language, I don't think you can even 
> take the pointer of anything unless you enable the unsafe 
> switch.

You're not showing a good grasp at all as to what a property is. 
In C# and in D, a property has *never* guaranteed the existence 
of a variable. In both cases, they allow syntactic sugar for 
letting the getter/setter pattern established by C++ look like 
variables.

This is important.

No, really.

Take std.bitmanip for an example of what I was talking about. It 
autogenerates properties for a bitfield. The types each property 
returns and lets you set are not at all indicative of the 
datatype underneath as it's literally just a bunch of bits. The 
property functions transform the data types given/return to/from 
a bitfield. What exactly do you suggest &property return if it 
was to return a char starting at bit 13 of a bitfield?

But we can go one further. __traits( allMembers, Type ) and 
__traits( getMember, Type ). Let's say you're writing an 
auto-serialisation library (or take std.json as an example). 
Assuming a property is a stand-in for another variable then what 
happens there when you're checking for the type of a member is 
the delegate type, and later on you'll get the actual variable. 
Now change it so that the type of a property returns the actual 
type. Now you're serialising a piece of data twice.

But what if our @property function increments another variable 
inside a class whenever you access it? That's pretty dangerous if 
you start treating the property as an actual type instead of a 
function/delegate.

Thus, your example:

     &t.x         // returns "ref int delegate()"
     &t.x()       // ok returns "int*", but defeats purpose of 
@property
     &(t.j = 10)  // shouldn't this return "ref int delegate(int)" 
?

First one I'd expect. Second one I'd expect. Third one I'd expect 
results in int*. You're getting the address of the results of the 
assign operation. Look at it this way: int val = (t.j = 10); 
You'd expect val and t.j to be 10, right? So why do you expect to 
get a ref int delegate(int) just because you ask for the address 
of it?

Like I said. Disagree. There's nothing that needs fixing here.