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.
