== Quote from Nick Sabalausky (a@a.a)'s article > "Sean Eskapp" <eatingstap...@gmail.com> wrote in message > news:j2ooko$15m4$1...@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.
