DIP23 Counter Proposal

[Dan]

On Thursday, 7 February 2013 at 21:55:12 UTC, Jonathan M Davis 
wrote:
> Except that mixins are generally unacceptable in APIs, because 
> they don't end
> up in the documentation. That means that this works only if you 
> don't care
> about documentation. So, it's almost useless. Putting @property 
> on there also
> looks better but isn't that big a deal. However, the lack of 
> documentation
> _is_ a big deal.
>

Again, why would you need to @property for the case of a 
read/write pattern.
Just make it public:

struct S {
   // Best int ever
   int i;
},
then switch to this as needed:
struct S {
   < accessors >

   // Best int ever
   int _i;
}
when needed.

This way you have documentation still in tact. If you want read 
accessor only from the start, go with:

struct S {
   mixin ReadOnly!_i;
   // Best int ever
   int _i;
}

I can understand documenting a member - quite important. But 
documentation on a generated accessor is not necessary. And if 
you customize it you can document it.

No extra feature needed.

Thanks
Dan