@property Incorrectly Implemented?

[Ethan Watson via Digitalmars-d]

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*.