Andrei Alexandrescu Wrote: > The code above is only loosely related. The code above contains a > definition initiated by the user.
True, but is there any technical difference for compiler? How the usefulness of the code change depending on whether it's written by the user or... huh?.. don't know what is the alternative... > The code a.b.c = 4 expresses the > intent of a user to effect a change a field that can be accessed later > through a.b.c, whereas with properties the code will in all likelihood > not do that. That's idealistic view of things. A programmer's imagination used to be more inventive :) > The question is very simple: given that we're used with a specific > semantics for a.b.c = 3, how can we address the fact that the semantics > of this familiar operation is so different (and likely so useless) when > properties replace fields? You're solving problems that never came to life. Well... only as syntetic examples. > > And what's the difference if c is field or property? > > It's b that's the problem. So do you attempt to dictate how library designers should implement their types, whether they should use value types or reference types? More important, are you trying to say that property is not allowed to return std.typecons.Unique since it's a value type?
