Generic code: @autoconst, @autopure, @autonothrow

[dsimcha]

== Quote from Rainer Deyke (rainerd at eldwood.com)'s article
> On 8/28/2010 19:29, dsimcha wrote:
> > Looks pretty good.  Won't work with BigInt because opBinary!"*" isn't pure and
> > can't practically be made pure.  A solution I propose is to allow the
> > annotations @autoconst, @autopure and @autonothrow for template functions.
> > These would mean "everything I do is const/pure/nothrow as long as all of the
> > functions I call are const/pure/nothrow".  As far as I can tell, this would be
> > reasonably implementable because the compiler always has the source code to
> > template functions, unlike non-template functions.
> On one hand, this addresses a real need.  On the other hand, D is
> already has a serious case featuritis.
> Is there any real reason why we can't apply these modifiers
> automatically to all functions?  (And by "real" I don't mean "it would
> be hard to do" or "it is incompatible with the archaic compilation model
> chosen by one D implementation".)
> Failing that, are the arguments for the inclusion of pure/nothrow/const
> really strong enough to justify all this extra cruft in the language?

Two reasons:

1.  Unless the function is a template, the compiler isn't guaranteed to have the
source available.  What if it's a binary-only library?

2.  The modifiers are part of a contract and part of the public API.  What if some
function just happens to be pure now, but you consider that an implementation
detail, not part of its specification?  Client code may rely on this, not
realizing it's an implementation detail.  Then, when you make the function impure,
your client code will break.