On Saturday, 17 September 2016 at 10:55:59 UTC, Ethan Watson
wrote:
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.
MSVC != C++
I'm not going to pay attention to a feature that isn't standard
and only Microsoft's compiler seems to have.
Since you brought it up though, it's a good chance to look at how
it behaves.
struct Test
{
int p;
int& prop()
{
return p;
}
__declspec(property(get = prop, put = prop)) int& magic;
};
void main()
{
Test test;
test.p = 10;
if(&test.p == &test.magic)
{
std::cout << &test.p << '\n' << &test.magic << '\n'
<< "magic";
}
}
I'll give you a hint, it prints magic. Imagine that.
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.
Yes, you can't take the address of a property in C#, with or
without unsafe on.
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.
I wasn't until you indicated that you were taking it personally
with that statement.
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 );
}
You have "get" and "set" in the C++ function, so no it doesn't
match it exactly. Semantics aside, you shouldn't be referencing
behavior of properties in a language that doesn't even have
properties. It's simply a way to emulate properties. If C++ had
properties, I would imagine they would behave like the above MSVC
implementation does. Shouldn't be held back by C++ for such a
reason, you can easily take off those property attributes and
that would probably be the saner solution. So that it actually
functions the same, in that you need the use the paranethese to
set and get the variable. That aside I doubt you ever take the
pointer of those getters and setters in C++ either.
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?
One use case is better than the zero use case it current holds..
And using it to identify whether a member is a property is a
misuse and i'd actually count that as a negative. So negative one
use case.
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*.
Alright then "blah blah blah" as you try to misdirect from all
the points that were made that you can't create a counter
argument for.
