Properties

[dsimcha]

== Quote from Miles (_______ at _______.____)'s article
> Daniel Keep wrote:
> > Yes, property syntax can simplify some cases, but this isn't one of them.
> One good distinction properties and normal functions ought to make is
> that functions should never be called without ()

Why?  This is really superfluous.  I for one think that code is often more
readable without the annoying empty parentheses around functions that don't take
any arguments.  This is especially true for member functions of classes and
structs, even moreso when chaining them such as foo.bar.baz vs. foo().bar().baz().

> , and properties should
> never have () unless it has a function type.
> Current syntax allows crazy things like:
> ----------
> 	exit = 1;	// it is not an assignment
> 	x = toString = getenv = "PATH";	// creepy, but valid D
> 	if (fork == 1)	// not comparing the value of a variable
> ----------

So?  The spec is not there to prevent people from doing stupid things (making it
harder to do stupid things *by accident* is a reasonable goal, but we're all
consenting adults here).  Anyone who would actually do stuff like this on purpose
in their code is an idiot and deserves what they get.  One could just as easily do
some pretty stupid things with operator overloading, casts, templates, you name
it.  Just because stupid things *can* be done with a feature doesn't mean the
feature should be removed.

> Also, currently, in D, if you have a property of a delegate type, you
> will have a mess.
> ----------
> 	int func2() { return 42; }
> 	/* this is a property */
> 	int function() prop() {
> 		return &func2;
> 	}
> 	void main() {
> 		auto x = prop;		// ok, x is a func ptr
> 		auto y = prop();	// unexpected: y is not int :-(
> 		static assert (is(typeof(y) == int));
> 	}
> ----------
> With properties, you forbid the above syntaxes.
> So, what is "better" about properties is not shorter syntax, but giving
> proper semantics for a given symbol.