On Monday, February 04, 2013 23:56:50 kenji hara wrote: > 2013/2/4 Andrej Mitrovic <[email protected]> > > > On 2/4/13, Andrei Alexandrescu <[email protected]> wrote: > > > I'm unclear that's a problem. > > > > The problem is you cannot replace a field with a @property function > > without breaking user-code when you take into account operator > > > overloading. Consider: > As an essential question, how often occurs rewriting fields to property? > > As far as I thought, such rewriting will cause: > 1. compile error by type mismatch (if you use &obj.field), > 2. or, success of compilation *without any semantic breaking* (if you don't > use &obj.field). > > I think the result is not so harmful.
There's also the issue a variable being able to be passed by ref, which a property function can't emulate, which is why it would be quite valuable to be able to mark a variable as @property - either to indicate that it's illegal to do anything with it that you can't do with a property function or to make it so that it lowers to getter and setter property functions and therefore can't be used with anything which wouldn't work with a property function. But if we could guarantee that swapping out variables and property functions wouldn't break code, then we could get rid of a _lot_ of property functions (since many of them don't do anything other than set and/or return the variable that they're wrapping). Because we currently allow stuff which only works with a variable or a function, we can't just seamlessly between variables and property functions, and it's not going to happen anywhere near as often for fear of breaking code. And many more people will simply create useless wrapper property functions around variables in case they need to add more code to them later (e.g. to validate the argument to the setter). We'd be much better off if anything which wasn't legal for both variables and property functions was made illegal for property functions and added a way to do the same for variables which are supposed to be treated as properties rather than explicitly being intended to be public variables like in a POD type. We could save a lot of boilerplate code if we can simply make it variables and property functions guaranteed to be swappable without breaking code. - Jonathan M Davis
