Fixing D's Properties

[Chad J]

BCS wrote:
> Reply to Chad,
> 
>> -------------------------------------(1)
>>
>> First, the very common ambiguity:
>>
>> Does
>> foo.bar++;
>> become
>> foo.bar( foo.bar + 1 );
>> or
>> foo.bar() + 1;
>> ??
>> This is why we can't write things like this:
>>
>> ubyte[] array = new ubyte[50];
>> //...
>> array.length++;
>> //...
>> array.length += 10;
>> // Note how builtin types use properties heavily.
>> Which means a large set of our beloved shortcut operators are
>> completely broken on properties.
>>
> 
> This is not an syntax  issue with how proposes are defined, but the 
> semantics of there use.
> It can be fixed with minor changes.

What minor changes?

If you're going to suggest giving implicit properties lvalueness, then 
this would break any code that relies on the quirks of current implicit 
properties.  I was hoping to preserve reverse compatibility with my 
solution, especially since Walter seems conservative about doing 
anything that breaks existing code.

> 
>> -------------------------------------(2)
> 
> [...]
> 
> this is the same as #1 (or am i missing somthing)
> 

Promotion != lvalueness

The idea here is that #2 is a natural consequence of #1, thus you see 
them as the same.  #2 though, has a different consequence for the 
programmer.  #1 is merely very annoying, while #2 causes nasty code 
extensibility issues.

>> -------------------------------------(3)
>>
>> Third, there is a problem with value types and properties. Consider
>> the following code:
>>
> 
> short version:
> 
> struct S {int i; void I(int j){i=j;} }
> struct P {S s void GetS() { return s;} }
> 
> P p;
> p.GetS.I = 5; // assignes 5 to temp, not member of p
> 
> This is a reference semantics issue. The same isses happens to general 
> functions.
> 

Exactly.  I don't want function semantics with my properties.  I already 
have function semantics with my functions.

>> -------------------------------------(4)
>>
>> Fourth, delegates get the shaft.
> 
> Short version:
> 
> void delegate() getDG();
> 
> getDG(); // calls getDG giving a delgate
> getDG(); // calls getDG, does not call returned delegate
> 
> 
> good point.
> 
>>
>> -------------------------------------(5)
>>
>> Fifth, delegates aren't over with yet.  This isn't nearly as bad as
>> the
>> other 4, but it should hit eventually.
>> Properties can be converted into delegates.
> [...]
>> The problem is, what if, for whatever reason, the author of similar
>> code
>> someday wanted to demote those properties back to fields?
>> In that case, the user code that relies on the delegate will fail.
> [...]
>> Realizing that this behavior of properties can be beneficial, it makes
>> sense to show that similar code can be written without properties and
>> without much added difficulty.
> [...]
>> struct Point
>> {
>> int x,y;
>> }
>> void main()
>> {
>> Point p;
>> int getX() { return p.x; }
>> int delegate() readX = &getX;
>> p.x = 2;
>> printf( "%d", readX() ); // prints 2
>> }
> 
> ouch! that sounds worse than the problem you point out.
> 

I disagree, but in light of what you value, it becomes an aesthetics vs 
functionality issue.

>> ========================================
>> How to fix it
>> ========================================
> [...]
>> *lvalue:  If foo is an lvalue, than foo = 5; should set foo's value to
>> 5, instead of evaluating to 5; and doing nothing.  Implicit write
>> properties fake this to some extent, but do not hold in the general
>> case.  Example (3) above and the foo++; and foo+=10; issues are
>> examples
>> where lvalueness is needed.
> 
> I would disagree. I would clam that the issue is that implicit 
> properties can be used a lvalues or rvalues, but not both.
> 

Still doesn't handle promotion/demotion between fields and properties.
Also, if you have a way to make the lvalue&rvalue semantics work, let me 
hear it.

> 
> 
> [......]
> 
> The basis of your thoughts seem to come from the idea that hiding the 
> fact that properties are functions would be a good thing. I would assert 
> that this is highly debatable. I will concede that the current semantics 
> of properties being not quite interchangeable with fields is sub 
> optimal. However fixing this by creating a new construct that, in the 
> end, is identical to a function but with a number of things forbidden 
> seems somehow wrong.
> 

Actually, I am suggesting that properties not be functions at all.  They 
will of course share the notion of a body of executable code, but for 
all intents and purposes they are a way of accessing data while 
introducing side effects.

> As I see it the issues you bring up amount to:
> 
> 1> no L/R-value usage (++, +=, etc, use as an inout or out arg)
> 2> they can lead to hard to find reference semantics issues
> 3> syntax problems with properties retuning delegates
> 4> not interchangeable with fields
> 
> #1 can be fixed without explicit properties
how?
> #2 is not at all a problem in my book
I have suffered many hours of debugging thanks to this "feature".  Don't 
tell me it isn't a problem!
> #3 This is a tiny corner case
I disagree, but regardless let's at least fix it while we are dealing 
with the related stuff.
> #4 this is a good point, however, as stated above, I don't like the 
> proposed solution. Also, the proposed solution doesn't fix the issue 
> because taking the address of a field is allowed, even with explicit 
> properties, this wouldn't work
> 

If the proposed solution is not good enough, please give a better one. 
Suggestions are welcome and encouraged.

As for the address of a field... perhaps if taking the address of a 
field returned a delegate... nah.
This is somewhat of a corner case, but you've got me there, for now.
I'd love to see someone come up with a slick solution to this.
I should also note that C# didn't seem to have this problem with its 
explicit properties.  That is probably because in C#, using pointers was 
considered "unsafe" and done very infrequently.  It makes me want to 
bust out C# again and see what happens when one tries to take the 
address of a property, and I probably will at some point.

Even if the addressing thing can't be fixed, I'd at least like to see 
the rest of the stuff get fixed.

> 
> IMHO there are a few minor issues with proposes that could uses a little 
> work. However I don't see much to be gained by you proposal for explicit 
> properties.
> 
>> This post is a bit lengthy.  So assuming you've read even part of it,
>> thank you for your time.
>> - Chad
> 
> 
> It's good to see people thinking about this stuff. I may not see your 
> ideas to be the "right" way but, then again, I want different things out 
> of D than many people do.
> 
>