On Friday, 16 September 2016 at 20:52:37 UTC, John wrote:
Your comment was out of place, saying properties don't need to
be changed is like saying @property shouldn't even be a D
feature cause you can create the same functional program in
C++, which does not have the property feature.
Stop reading rubbish that isn't there.
And pay attention. MSVC has the __declspec( property ) extension.
You also made a reference to C#, which doesn't even allow you
take address of
And? Properties in C# are a massive example of a comparable
feature where executed code is syntactically treated in some ways
to a variable.
So I don't know what you mean by that's how I want to play,
when you instigated said argument.
I indicated you're taking it personally. Which you are.
It's not really that important. What it allows is returning
references. You can make a comparison to any other language
that has properties it doesn't really matter. This is how D was
implemented. If they wanted to be like every other language
then it shouldn't have been allowed to even return a reference.
But it is does, that's how it's implemented and odds are it
probably won't change now to not allow it. D also has the "&"
implemented, what I am discussing is whether it was implemented
correctly or not. Honestly it is no implemented correctly. To
the point I would actually rather they remove the functionality
so that you can't take the address of a property. If they are
not willing to change it to function in a different way.
Taking the address of a property and getting a function type is
important.
Did you know that this C++ class:
class SomeObject
{
virtual int getSomeValue() const;
virtual int setSomeValue( int value );
};
Matches up exactly to this D class:
extern( C++ ) class SomeObject
{
@property SomeValue() const;
@property SomeValue( int value );
}
This has been brought up by someone else. I honestly don't
understand why it's such a hard concept.
Because your understanding of the technical details is limited...
Maybe you don't come from C++ and thus don't use a language
that provides a way to take the address of things.
...and you're assuming you know more than what I do on the
subject.
That's why it keeps being brought up.
Calm down.
Anyways a bitfield can't actually represent a single, there's
no type for a bit. The smallest type is a byte, which is 8
bits. So even if it wasn't a property there's no way you can
take the address of a bit. So that's the first issue, you are
trying to use an example that doesn't make sense even outside
the concept of properties. The second issue is, this is defined
behavior. You can't take the address of a rvalue, there's an
ideone link in my previous post show this if you missed it. So
taking the address of a property would return an error if it
didn't return a reference.
What you're suggesting, and why I brought up the example, is to
change the implementation details of properties for *one* use
case. This has wide ranging implications that you've clearly not
thought of. Like if I was to take the address of that property
for the purposes of exposing a function to C++. You want to make
it so I don't get that function? Or that there's some extra
convoluted method of getting it solely because you think a
property should be something that it's not?
Well that's how it is currently implemented actually.
struct S
{
@property int prop() { return 0; }
}
writeln(typeof(S.prop).stringof) // prints "int", not
"delegate"
Read further. I have suggested that the property resolution order
gets changed so that this ambiguity goes away.
blah blah blah
Yeah I covered everything else already. Not helping your cause by
stating your example that started this topic was *satirical*.
