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