Properties

[Miles]

Nick Sabalausky wrote:
> True, but my main point was, however the language ends up handling the 
> details of property getters/setters, it's not going to be as general as 
> ordinary functions, and thus certain aspects of the syntax can/should be 
> simplified.

In this case, simplifying would be more complex.

Under the hood, when you define getters and setters, you are defining
functions, and function overloading is an inherent feature of the
language. In fact, the current "property" feature of D already supports
many overloaded setters for different types, since they are just normal
functions.

For example, consider the property definition:

	public property int width {
	  get() { return width; }
	  set(int value) { width = value; }
	  set(float value) { width = value + 0.5; }
	}

That would generate overloaded functions with different signatures, lets
say that, under the hood, the compiler generates:

	int __get_width();
	int __set_width(int value);
	int __set_width(float value);

Then, when code that accesses the property is compiled, something that
looks like

	width = x;

will, in fact, be threated as

	__set_width(x);

and so, the compiler will choose the appropriate __set_width() function
with the signature that matches the above call.

So, restricting a property to have only a single setter will end up
creating unnecessary restrictions for something that is already native
to the language.

> You're absolutely right that properties need to be able to return an rvalue 
> from an assignment, but I see no reason why that can't or shouldn't be 
> transparent to the person writing the property.

They could, no problem.

> I'm still not 100% convinced that we should be using properties to do type 
> conversions, although I suppose it may have some legitimate uses...

It is not just about type conversions... it is that the feature is
already something natural for the language.

> But anyway, even with the possibility of a property handling multiple types, 
> I still don't think it means we can't or shouldn't have a nicely trimmed 
> syntax for the more typical cases:
> 
> property int x
> {
>     set { this = this.new; }
>     get { return this; }
> 
>     set char[] { this = StringToInt(this.new); }
>     get char[] { return IntToString(this); } // If we ever got 
> overload-on-return-value
> }

Not for getters, please... the type of the getter should be the type of
the property, or that would create a lot of complexity for the language
(that is also the reason you don't overload functions based on the
return type).