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

== Quote from Pillsy (pillsbury@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.