Properties

[Miles]

Bill Baxter wrote:
> Not sure what you mean by that.  It's just  foo vs &foo in most cases.
> ...Except for some cases like where you're trying to return a delegate.

It is more tied with the intuitive use of symbols. 'foo' is a function,
add a '&' before and you take its address, add a '(...)' after and you
make a call and take its return value. The implicit call syntax without
parentheses breaks this intuitive use.

In fact, if you follow the principle of orthogonality, instead of
calling the function without parameters, it would be much more sensible
to have 'foo' return the function address, and deprecate the address
operator. Then you could have functions and function/delegate pointers
with similar semantics (principle of least surprise).

---------
	int func1() { return 1; }

	auto a = func1;		// 'a' is a pointer to func1
	auto b = &func1;	// ERROR, or deprecated way of above
	auto c = func1();	// calls func1 and returns int 1

	int function() func2 = func1;

	auto d = func2;		// 'd' is a pointer to func1
	auto e = &func2;	// 'e' is a ptr to ptr to func
	auto f = func2();	// calls func1 and returns int 1
---------

Note that this way you have less surprises. Both func1 (the real
function) and func2 (pointer to function) behave in similar ways. In
current D, 'a' will be different than 'd', while 'c' will be equal to 'f'.

The reasoning for deprecating &func1 is that func1 is not a variable,
neither it is an lvalue.

But now it is quite already too late to fix this, unless we go through a
long period of deprecating the current behavior, until we can implement
the new sane one.

> He may want to retain the ability to pass it as a delegate to some
> other function too.  If you make properties distinct from functions,
> then I don't think this can be allowed.

Yes, they are basically two distinct, mutually exclusive, compromises. A
property is syntax sugar to a collection of delegates (all of them share
the same scope). Properties are "views" that aim to behave as much as
possible as variables. Optimally, you must ignore completely if a given
symbol is a property or a variable. So, it makes little sense to pass a
property as a delegate to a function.

But it is still possible, and the solution actually keeps the
fundamental property that variables and properties should be almost
indistinguishable:

----------
	int m_prop;

	property int prop {
		get() { return m_prop }
		set(int value) { m_prop = value; }
	}

	// lets say that func expects a setter
	func1( (int value){ prop = value; } );

	// and func2 expects a getter
	func2( (){ return prop; } );
----------

See? You passed delegates to the functions, and you kept the compromise
that the code doesn't make distinction between properties and variables.
The following code (taking the property out) is still valid:

----------
	int prop;
	func1( (int value){ prop = value; } );
	func2( (){ return prop; } );
----------

> So you'd need to have the
> property and a function that wraps the property.

Exactly, or, instead of a function, an inline delegate is enough. As
shown above, you win because then the code becomes insensitive to
whether prop is a property or a variable.

> Then you've just made more work for yourself.

This is such a corner case that I think that using inline delegates is a
good enough solution.

>    Hmm, maybe properties should be
> allowed to be turned into delegates.

The compiler could provide a syntax for that. Like I said, a property is
just a collection of delegates under a single identifier. For example,
tentative syntax:

----------
	property int prop { ... }

	auto setter = property(prop).set;
	// setter has type 'void delegate(int)'

	auto getter = property(prop).get;
	// getter has type 'int delegate()'
----------

But I think this is a secondary feature (if we keep demanding solutions
for the corner cases, we will never have the solution for the biggest
problem). I could live fine without this feature.