Why aren't function attributes inferred?

[Nick Sabalausky]

"Sean Eskapp" <eatingstaples at gmail.com> wrote in message 
news:j2p7mh$1uk2$1 at digitalmars.com...
> == 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.

Well, that too. But the main thing is the checked guarantees.