www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why aren't function attributes inferred?

reply Sean Eskapp <eatingstaples gmail.com> writes:
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?
Aug 20 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2011 06:50 PM, Sean Eskapp wrote:

 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?


This sort of inference is already done for function/delegate literals 
and template functions.

It is not done for other functions, because eg. their code is not 
necessarily available.

int foo(int x) pure; // how would you infer purity here?

Also, if normal functions would infer those attributes, they would be 
leaking implementation details all over the place. If a pure 
implementation would have to be changed to a non-pure one, all code that 
relied on the undocumented but inferred purity would break.
Aug 20 2011
parent Sean Eskapp <eatingstaples gmail.com> writes:
== Quote from Timon Gehr (timon.gehr gmx.ch)'s article

 On 08/20/2011 06:50 PM, Sean Eskapp wrote:

 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?


 This sort of inference is already done for function/delegate literals
 and template functions.
 It is not done for other functions, because eg. their code is not
 necessarily available.
 int foo(int x) pure; // how would you infer purity here?
 Also, if normal functions would infer those attributes, they would be
 leaking implementation details all over the place. If a pure
 implementation would have to be changed to a non-pure one, all code that
 relied on the undocumented but inferred purity would break.


I understand your point about functions with no definition, but your point about
normal functions holds true anyway. If I have a pure function foo(), and a
function bar() which relies on the purity of foo(), then changing the purity of
foo() would break bar()'s internals. Either way, purity should still be inferred
at optimization time, where it could really make a difference!
Aug 20 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Sean Eskapp" <eatingstaples 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.
Aug 20 2011
parent reply Sean Eskapp <eatingstaples gmail.com> writes:
== Quote from Nick Sabalausky (a a.a)'s article

 "Sean Eskapp" <eatingstaples 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.
Aug 20 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Sean Eskapp" <eatingstaples gmail.com> wrote in message 
news:j2p7mh$1uk2$1 digitalmars.com...

 == Quote from Nick Sabalausky (a a.a)'s article

 "Sean Eskapp" <eatingstaples 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.
Aug 20 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


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


Maybe  safe too is usable to improve some optimizations, I don't know. Maybe
simplifies pointers strictness analysis?

Bye,
bearophile
Aug 20 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 20, 2011 16:50:32 Sean Eskapp wrote:

 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?


As of 2.054,  safe, pure, and nothrow are inferred for delegates and templated 
functions. This is because whether they can be  safe, pure, or nothrow depends 
entirely on the types that they're instantiated with. For normal functions, 
there is no such inferrence. It's not needed.

As for just assuming attributes, the language was designed like pretty much 

is marked with an attribute, it doesn't have that attribute. It _could_ have 
been designed the other way around, but then all of your attributes become 
stuff like mutable, impure, and throw. It doesn't really buy you anything. It 
just changes what attributes you have to mark stuff with. And whether you'd be 
using more attributes or fewer attributes with such a scheme would depend 
entirely on the code. But such a scheme would be entirely foreign to most 
programmers of C-based languages.

- Jonathan M Davis
Aug 20 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 20 Aug 2011 20:23:44 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Saturday, August 20, 2011 16:50:32 Sean Eskapp wrote:

 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?


 As of 2.054,  safe, pure, and nothrow are inferred for delegates and  
 templated
 functions. This is because whether they can be  safe, pure, or nothrow  
 depends
 entirely on the types that they're instantiated with. For normal  
 functions,
 there is no such inferrence. It's not needed.


Well, and also because you can't template purity,  safety, and um...  
nothrow-ity :)

-Steve
Aug 22 2011