On Apr 11, 2012 4:14 PM, "Nick Sabalausky" < seewebsitetocontac...@semitwist.com> wrote: > > "Kevin Cox" <kevincox...@gmail.com> wrote in message > news:mailman.1599.1334099575.4860.digitalmar...@puremagic.com... > > > >I was wondering why they could not be implied from the code itself. > > That question comes up a lot. The thing is, that would completely defeat the > point. The point is that you want the compiler to *guarantee* that certain > specific functions are pure/@safe/const/nothrow, etc. > > If you make a change that prevents a function from being > pure/@safe/const/nothrow, and the compiler just simply accepted it and > internally considered it non-pure/non-whatever, then you haven't gained > anything at all. It'd be no different from not even having any > pure/@safe/const/nothrow system in the first place. At *best* it would just > be a few optimizations here and there. > > But if the compiler tells you, "Hey, you said you wanted this function to be > pure/whatever, but you're doing X which prevents that", then you can > actually *fix* the problem and go make it pure/whatever. >
Makes sense.