new DIP5: Properties 2

[Chad J]

Andrei Alexandrescu wrote:
> 
> My perception is that there are a few vocal people. The protests have
> been historically against the stupid "writeln = 42" which we must get
> rid of.
> 

Seems odd to me.  I thought the unpopular bit was the lack of
lvalue-ness and how "array.length++;" did not work.  No idiot would
write "writefln = 42;" in serious code.  It's easy to avoid since you
have be rather intentional about it.

> I have a dream.
> 

I feel like ranting ;)

> * Parameterless functions still can be called without "()". People will
> realize that it's a prejudice to believe that this impedes code
> understanding, and their eyes and wrists will thank them.
> 

Earlier I was thinking yeah ok w/e that's fine.  Now I'm thinking these
are just evil.  But only when the function returns a value-type.  void
functions are alright.  Ref returns may or may not be alright.

It's not because of "writefln = 42;".

It's because of this:

// Library code
struct Rectangle
{
	float x,y,w,h;
	// etc blah blah
}

class Widget
{
	Rectangle _rect; // eww no optional backing storage
	Rectangle rect() { return _rect; }
	//...
}

// User code (probably test code in this case...)
auto widget = new Widget(...);
widget.rect.w = 200;
widget.rect.h = 100;

// End
A few hours later this poor library developer takes a break from the
debugger and writes a small experiment.  The conclusion is
"AARRGGGHHH!".  He runs to the news group to bitch and moan, and someone
responds, "yeesh use ref return and RTFM already".  Bad day.

This is only the example that pops to mind.  I am sure there are cases
where the library writer may intentionally NOT ref return, and the user
will miss this and get bitten.  When the library writer and user are the
same, things only goes downhill.

> * The syntax "foo = bar" is rewritten into "foo(bar)" IF AND ONLY IF the
> expression "auto __x = foo, __x = bar" is compilable.
> 

I seem to know exactly what you said with great mathematical precision
and certainty.  I have no idea what this actually DOES though :/

(In another post you mentioned this being a guarantee of a getter, but
there seems to be more to it, such as type equality between foo and bar.)

> * The non-uniformity regarding parameterless functions returning
> parameterless functions is acknowledged but considered minor.
> 

O.O

R-R-Really?!

So you're just going to give up?

So fields can return functions but properties cannot?

> Yum.
> 
> 
> Andrei

At the end of all of this "array.length++;" still does not work like one
would hope.

That's because

	ref int length() { ... }
	// int length(int foo) { ... } // hint: this is not used

	length++;

is not the same as

	int length() { ... }
	int length(int foo) { ... }

	length(length()+1);

I don't know if ref returns are expected to be the be-all-end-all
solution to the lvalueness problem of properties, but it won't work
here.  The length property will be incremented, but the unfortunate user
will find out later that some dead stack variable changed but no new
space was ever made.  Not unless they are lucky and such things remain
as compiler errors.