Generic code: @autoconst, @autopure, @autonothrow

[dsimcha]

== Quote from Pillsy (pillsbury at gmail.com)'s article
> Andrei Alexandrescu Wrote:
> > On 08/28/2010 08:29 PM, dsimcha wrote:
> > > An issue that comes up very frequently when trying to use
> > > const, pure or nothrow in generic code is lack of knowledge
> > > of whether the functions you're calling are
> > > const/pure/nothrow.  For example:
> > > T abs(T num) pure nothrow {
> > >      return (num<  0) ? -1 * num : num;
> > > }
> [...]
> > > A solution I propose is to allow the annotations @autoconst,
> > > @autopure and @autonothrow for template functions.
> [...]
> > > Does this sound like it could feasibly be implemented and
> > > would work well?
> > Yah, with the growing interest in applying qualifiers at a larger scale
> > (and making Phobos a good example of such) this is quite timely.
> > I've been mulling myself over a similar proposal.
> > What I had in mind is a bit more structured - it would allow
> > selecting a type or an expression and assessing its
> > constness/purity. That would be done just like .sizeof and
> > .stringof work - by defining two more special members
> > .constof, .pureof, .nothrowof. For example:
> > T abs(T num) (-1 * num).pureof (-1 * num).nothrowof {
> >      return (num < 0) ? -1 * num : num;
> > }
> Could something along the lines of a .qualof member work, for those
> times where you want to duplicate all relevant qualifiers? That seems
> likely to be the general case, and could considerably reduce the
> verbosity involved.
>     T abs(T num) (-1 * num).qualof {
>       return (num < 0) ? -1 * num : num;
>     }
> is even shorter, and would have the possibility of also handling concerns of
constness and sharedness and the like properly.
> Cheers,
> Pillsy

My concern with proposals that require you to explicitly check specific statements
is that they won't scale to larger functions where there are a lot of things that
need to be checked.  I'm worried some signatures might become so complicated with
qualification checking as to make protected virtual abstract base pure virtual
private destructors look tame.  Until someone can explain how this proposal would
scale at all, let alone gracefully, to needing to check the
purity/constness/nothrow-ness/safety of a lot of things, I don't think we can
seriously consider it.