Do we want functions to act as properties, or merely omit parens for ufcs/chaining?

[Chad Joan]

On 01/29/2013 06:26 AM, eles wrote:
> On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
>> to the one used for functions. That way, you can avoid verbosity and
>> the need to use implicit parameters
>
> What do you eran from that? Sparing "value" as a reusable identifier?
> You define a getter at the top of the class, then finding a setter three
> screens lower and you finnaly learn that the property is not that
> "read-only"?
>
> I think the first step into better property
> definition/implementation/comprehension would be exactly that: to force
> the code of the getter and the code of the setter to stick together.
>
> Yes, exactly at the user of a property I was thinking. That user is also
> a programmer, but he does not do the implementation of the property,
> just using it.
>
> The confusion does not lie with that user, but it was sparked when the
> implementation decision was made, in the very heads of those who started
> implementing properties as just-another-function.
>
> This confusion propagates from the implementors to the user, as the
> (usage) syntax issues are issues for the user.
>
> It also does not help that, for the time being, the users of properties
> are also the implementors of properties. There is not much objectivity
> in this case.

IIRC, C# goes like this:

property int foo
{
	get
	{
		return m_foo;
	}
	
	set
	{
		m_foo = value;
	}
}

C# properties have a couple disadvantages:
- They introduce an extra nesting level.
- There is a possible nonsense error if someone places code outside of 
the get/set but inside the property scope.
- You don't get to determine how the setter value is passed.  ref? auto 
ref? const?
- They use 4 keywords, whereas we can get away with 2 probably.
- Things get uglier when you add D's function pure and const annotations 
to it.

I think there are another disadvantage or two that Andrei mentioned 
before in a property discussion a couple years ago.  He fairly well 
convinced me that C#'s property syntax isn't the right thing for D.

Semantically, they accomplish the same thing as D's properties: they get 
lowered into two methods, one getter and one setter.  There has to be 
/some/ way to attach executable code to a symbol for this properties 
concept to work at all.