DIP23 Counter Proposal

[Jonathan M Davis]

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