Why aren't function attributes inferred?

Sean Eskapp eatingstaples at gmail.com
Sat Aug 20 14:07:29 PDT 2011


== Quote from Nick Sabalausky (a at a.a)'s article
> "Sean Eskapp" <eatingstaples at gmail.com> wrote in message
> news:j2ooko$15m4$1 at digitalmars.com...
> > Since the compiler can clearly tell when a function is not const, safe,
> > pure,
> > or nothrow, why can't they just be assumed, unless proven otherwise?
> That would defeat the whole point.
> Suppose it did work that way: If a function is *supposed* to be const, safe,
> pure, or nothrow, and you make a change that violates that, then you'll
> never know. It won't tell you. If it just simply decided "ok, so it's just
> not a safe/pure/whatever function", then what would be the point of having
> safe/pure/etc functions? They wouldn't serve any purpose. It would just be
> arbitrary metadata that sits around doing nothing.
> The whole point of those attributes is that if a function is *supposed* to
> have certain guartantees, the compiler will actually *tell* you when you
> violate them.

I was under the impression that it helped some with optimization - purity, for
instance, can help with inlining and caching. Safety wouldn't be useful, as far as
I can tell.


More information about the Digitalmars-d-learn mailing list