On 2009-07-28 22:33:53 -0400, Walter Bright <[email protected]> said:

The issue is what if b is a property, returns a temporary object, and that temp's .c field is uselessly set to 3?

It's a classic problem with properties that are implemented as functions.

With the local namespace approach I propsed a little while ago, you could allow "subproperties":

        namespace a {
                namespace b {
                        namespace c {
                                int opGet() {...}
                                void opAssign(int) {...}
                        }
                }
        }

or (alternate syntax for the above):

        int a.b.c.opGet() {...}
        void a.b.c.opAssign(int) {...}

Although it'd be somewhat clumbersome to redefine every member of a struct like this each time you make a property just so assigning to it works fine (I guess a mixin or some compiler magic could help).

I don't see how C#'s special property syntax adds any value for dealing with this.

Me neither.

One thought I had was to simply disallow the '.' to appear after a function style property.

I think that's a little harsh. If you return something by reference (like an object), the waterver you do to that object won't be lost. It's for value types (like structs) that this is a problem.


--
Michel Fortin
[email protected]
http://michelf.com/

Reply via email to