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

[Chad Joan]

On 01/29/2013 09:14 AM, eles wrote:
> 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.
>

My point is that this is another error that has to be coded into the 
compiler.  Another error that can show up on your screen.  Generally it 
is a better course to make it impossible for errors to happen at all.

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

I do care.  Whether things are const or not matters a lot.  You wouldn't 
be able to write (foo.prop = "hi") if prop has a non-const parameter. 
Also, if the property type is some large struct, then I'll want to pass 
it as ref to avoid a huge copy overhead.

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

Semantics != Syntax

"Semantically" is a really important qualifier in formal language 
discussion.