On Thursday, February 07, 2013 17:34:19 Andrei Alexandrescu wrote:
> On 2/7/13 4:55 PM, Jonathan M Davis wrote:
> > On Thursday, February 07, 2013 16:12:34 Steven Schveighoffer wrote:
> >> On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis<jmdavisp...@gmx.com>
> >>
> >> wrote:
> >>> struct S
> >>> {
> >>>
> >>> @property int i;
> >>>
> >>> }
> >>
> >> struct S
> >> {
> >> mixin(boilerplateProperty("i"));
> >> }
> >>
> >> I don't see this as a difficult problem to solve.
> >
> > 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.
>
> Well there's the version(DDoc) ... etc. possibility.
Except then you're being forced to throw in a different sort of boilerplate
code.
version(D_Ddoc)
{
/// DDoc for prop
int prop;
}
else
{
mixin(boilerplateProperty!int("prop"));
}
is enough extra that it's arguably worse than just declaring the property
functions. If you could do
/// DDoc for prop
mixin(boilerplateProperty!int("prop"));
then that would be okay (though it would be uglier than just putting @property
on it to do the same thing). But we can't do that, not and have it show up in
the documentation.
- Jonathan M Davis
