On 08/29/2010 06:42 AM, Rainer Deyke wrote:
On 8/28/2010 22:33, dsimcha wrote:
2.  The modifiers are part of a contract and part of the public API.  What if 
some
function just happens to be pure now, but you consider that an implementation
detail, not part of its specification?  Client code may rely on this, not
realizing it's an implementation detail.  Then, when you make the function 
impure,
your client code will break.

That may or may not be a compelling argument against always
auto-detecting pure.  It seems stronger as an argument against having
pure as a language feature at all.  (How can you know ahead of time that
a logically pure function will remain physically pure?)



I'm not sure I understand what you mean, but if you put pure on a function in your library, you're saying to whoever using it that it is and probably will always be pure. Also, if you put @autopure on it implies that if the template input is pure in the right places, the function will be pure.

If we remove pure, or make everything always @autopure, this benefit disappears. Which is why I don't know if I get your point.

Reply via email to