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
