--- Comment #2 from Sobirari Muhomori <> 2009-10-02 
04:51:21 PDT ---
(In reply to comment #1)
> (In reply to comment #0)
> > 2. When a function takes a reference type parameter, the chanses are slim, 
> > that
> > the return value doesn't depend on the referenced data. 
> Yes.
> > So the referenced data must be immutable.
> That conclusion does not follow. I don't think you're seeing all of the
> benefits of 'pure'.
> Consider foo(a) + foo(a). This can be changed into 2*foo(a), even though a is
> not immutable.

You participated in discussion of bug 3057, where I described my view of the
problem. The question is *how* can you benefit from advertised pureness of in
fact impure functions?

> It is true that in the case where all parameters are immutable, additional
> optimisations (such as caching) can be performed. But there's more to pure 
> than
> that.

But what you did with foo(a)+foo(a) if not caching? You effectively cached the
result of function without any requirement for immutability.

> > 4. (??) Replace immutability of explicit pointer type with constness, since
> > even if the referenced data is immutable, the code doesn't know, where the
> > immutable data ends and can access subsequent possibly mutating data. This 
> > will
> > instantly make any function, taking a pointer, impure. This should not 
> > apply to
> > objects and byref data.
> That's a memory integrity issue, not a purity issue. That could only happen in
> an unsafe module.
> You are asking for a feature to be removed from the language, but I'm not
> really sure why.

I'm asking to remove a bug from the language, because I think it's incorrect to
allow marking impure functions as pure (and later "benefit" from this). I'm
just proposing an easy solution to the problem.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to