While we're lynching features, how bout' them omittable parens?

[Steven Schveighoffer]

On Tue, 19 May 2009 13:32:35 -0400, Ary Borenszweig <ary at esperanto.org.ar>  
wrote:

> Steven Schveighoffer wrote:
>> On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig  
>> <ary at esperanto.org.ar> wrote:
>>
>>> Jesse Phillips escribió:
>>>> On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote:
>>>>
>>>>> "Chad J" <chadjoan at __spam.is.bad__gmail.com> wrote in message
>>>>> news:gut1od$l56$1 at digitalmars.com...
>>>>>> Lionello Lunesu wrote:
>>>>>>> "Chad J" <chadjoan at __spam.is.bad__gmail.com> wrote in message
>>>>>>> news:gut0f2$jc0$1 at digitalmars.com...
>>>>>>>> Nevermind properties.  Any chance we can forbid the omittable
>>>>>>>> parentheses, at least in the lhs of an assignment expression?
>>>>>>>>
>>>>>>>>
>>>>>>> This is not because of the omittable parens. Even with added parens
>>>>>>> that code should not compile!
>>>>>>>
>>>>>>>
>>>>>> Agreed!
>>>>> I still want to get rid of omittable parens (and  
>>>>> function-call-as-a-lhs)
>>>>> anyway. They're a horrible substitute for a real property syntax.
>>>>  I don't like C# properties, IMO it is pointless overhead. I agree  
>>>> you can misuse the omittable parentheses, but what is a "real"  
>>>> property syntax? Seems to me both D and C# provide the same syntax  
>>>> they are just set up differently.
>>>
>>> What I like in C# about properties is that they are like "pure"  
>>> functions, so they don't have side-effects (this is just a contract on  
>>> the semantic of properties). What that means is that you can invoke  
>>> them while debugging code and be sure they don't alter the flow of  
>>> execution. So when watching a variable you automatically can see it's  
>>> properties, not just it's variables. I find that very useful, since  
>>> properties basically tell you what's the representation of an object,  
>>> what's it's meaning (hiding how it is implemented, ultimately).
>>>
>>> Currently you can't do that in a D debugger because a method like "int  
>>> foo();" could have side effects.
>>>
>>> So for me, properties are way more than just syntax sugar.
>>  AFAIK, this is not enforced by the compiler...
>>  I write C# properties that have side effects.
>
> That's what I said it's a contract on the semantic of properties. :)
>
> But now I'm curious: what kind of properties do you write?

Not all the properties I write have side effects :)  Most are simply  
virtual data members.

One I just wrote recently is something that returns a unique ID (which  
changes the next time you access it).  I'm unsure what would happen if you  
read the property during debugging...

I suppose I could have made this a function instead, but my point is, if  
the compiler doesn't enforce it, you can't really rely on the contract.

-Steve