DIP23 Counter Proposal

Jonathan M Davis jmdavisProg at gmx.com
Thu Feb 7 21:52:40 PST 2013


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<jmdavisProg at 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


More information about the Digitalmars-d mailing list