On Friday, February 08, 2013 22:38:35 Era Scarecrow wrote: > If on the other hand if 'i' was intended part of the API, you > can rely on it being ref-able unless there's a major change in > design. > > struct S { > int i; /// iterator number, part of API > ref auto front() {return i;} /// > ... > }
The idea is that it's supposed to be part of the public API and that you're supposed to be able to add code to it later which does additional checking or completely changes how its implemented internally. This is trivial to do with functions, because they provide proper encapsulation. You can change the implementation as much as you like without breaking the API. But many getter and setter functions just get and set a variable without doing anything else making them useless boilerplate beyond the fact that they provide encapsulation. So, what property functions are trying to do is allow you to declare it as a public variable first (avoiding the boilerplate) and then only turn into property functions (with the variable being private) if you need the getter or setter to do something extra or different later. The one hitch in that is the fact that there a few things that you can do with a public variable that you can't do with a property function - things that you _don't_ want anyone doing with the public variable (like taking its address or passing it by ref). So, lacking a way to mark a public variable as a property, choosing to start with a public variable makes it likely that you're going to break code when the variable is converted to a pair property functions later. On the other hand, if you can mark the variable as a property (in which case the compiler either makes it illegal to do anything with that variable that you couldn't do with property functions, or it just lowers the variable to a pair property functions, and the variable isn't actually public anymore), then you can avoid breaking code. But the idea is to do this in a way that's transparent to users of the struct or class. They shouldn't care how a property is implemented. We want the encapsulation even when it's declared as a public variable (because we're really just looking to avoid boilerplate code). What I'm describing here is how properties are typically presented in C#, and it's what a lot of us would like to be able to do with D. - Jonathan M Davis