Paren elision on nullary calls

[Scott L. Burson]

In article <dvstvm$2cr7$1 at digitaldaemon.com>, Jarrett Billingsley says...
>
>"Scott L. Burson" <Scott_member at pathlink.com> wrote in message 
>news:dvss27$29p9$1 at digitaldaemon.com...
>> In article <dvoeak$2gvi$1 at digitaldaemon.com>, Oskar Linde says...
>
>Your topic made me laugh.  It's probably not meant to be funny, but it just 
>sounds so funny :)

Remember: subduction leads to orogeny! :)

>I suppose a (d) would be to create an explicit property syntax, like in C#, 
>which would eliminate this whole problem.

Hmm.  If I understand correctly, you're suggesting that the primary purpose of
allowing paren elision in the first place is to unclutter property references.
That's presumably not the only purpose, since the elision rule applies to all
named function calls, not just member function calls.  Still, it could be the
main purpose, and as you say, there might be another way to satisfy that
purpose.

>In addition, I would imagine it'd make it one step closer to being able to 
>do
>
>obj.prop+= 5;
>
>As if you were to define the property as
>
>class A
>{
>    private int mValue;
>
>    public property int prop
>    {
>        set(int value)
>        {
>            mValue = value;
>        }
>
>        get()
>        {
>            return mValue;
>        }
>    }
>}
>
>The compiler would know that the property is read and write, and would know 
>exactly how to compile an += expression. 

Yes, I agree, this seems better than the way D currently defines properties --
though a little more verbose, it seems clearer.  It also opens up the
possibility of specifically overloading the behavior of `+=' etc.  While this is
not very interesting in the case of ordinary addition, it can be a hook for
useful optimizations in cases where `+' means something more complex like set
union.

-- Scott