Generic code: @autoconst, @autopure, @autonothrow

dsimcha dsimcha at yahoo.com
Sat Aug 28 20:52:57 PDT 2010


== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> 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;
> }

This may work well in Phobos because it's the standard library, so a lot of effort
could reasonably be put into making stuff like this right.  For run of the mill
generic code, though, this just seems too verbose.  If this is what I had to
write, about the only time I would use it is when hacking Phobos.  I probably
would even be too lazy to use it for my more specialized libraries like dstats.
Also, how does it scale to the case where you need to evaluate the purity of
multiple expressions to decide how to qualify a single function?

> The @autoxxx stuff arguably makes this example and probably many others
> easier to write. What I fear in the case of @autoxxx is that the
> compiler will be unable to decide cases in which there are cycles of
> @autoxxx.

Good point, though in practice I can't think of any time I've written or seen
mutually recursive templated code.  I guess the cycle-breaking logic could just
treat the mutually recursive functions as effectively being one function.  If all
would compile when qualified with x, then all are x.  Otherwise, none are x.  Is
it more complex than this for some reason I'm not thinking of?

BTW, now that I think of it, I guess these proposals also apply to @safe.


More information about the Digitalmars-d mailing list