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

[eles]

On Tuesday, 29 January 2013 at 13:51:05 UTC, Chad Joan wrote:
> 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
> IIRC, C# goes like this:

YRC.

> 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.

The compiler will scream at you. This is why it analyses the 
code, to make sure it understands it.

> - You don't get to determine how the setter value is passed.  
> ref? auto ref? const?

Frankly? Why you would care? You only write a.x=b. How it is b 
passed? It is the job of the compiler to pass b, not yours.

> - They use 4 keywords, whereas we can get away with 2 probably.

Yes. This is why brainfuck become no.1 language ever invented, 
because it uses very few keywords. And this is why Java never 
really took off, just because it introduces new keywords like 
extends and implements instead of our lovely :. Lovo of keywords 
changed the world...

> - Things get uglier when you add D's function pure and const 
> annotations to it.

*Everything* become uglier with that. Everything.

> 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.

If they are the same, why they are different to the point that 
you love one but hate the other?