"Sean Eskapp" <eatingstap...@gmail.com> wrote in message news:j2p7mh$1uk2$1...@digitalmars.com... > == 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.
Well, that too. But the main thing is the checked guarantees.