Generic code: @autoconst, @autopure, @autonothrow

[dsimcha]

== Quote from Peter Alexander (peter.alexander.au at gmail.com)'s article
> On 29/08/10 2:29 AM, 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;
> > }
> >
> > Looks pretty good.  Won't work with BigInt because opBinary!"*" isn't pure and
> > can't practically be made pure.
> I think the problem here is *not* that it's difficult to tell whether a
> function can be pure, but the fact that BigInt's binary product should
> be pure (because it is, in the mathematical sense).
> This is just the whole const without mutable thing all over again i.e.
> there exist logically const member functions that change the state of
> their members (caching is the canonical example of this). This is why
> mutable exists. Similarly, there exist logically pure function that
> change the global state, or allocate memory (such as BigInt's op* here).
> There needs to be some way around that.
> If there cannot be any way around it then pure should be dropped
> altogether because the language simply cannot support it.

Part of the point of purity is to provide guarantees useful for multithreading.
For these cases logical purity isn't what's important.  Physical purity is.  I
agree that D's purity system is a bit conservative and should ideally be made less
conservative, but it doesn't change the fact physical purity is what matters to
threading.