[Issue 3359] New: Cannot parse pure/const/immutable functions with inferred return type

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3359

   Summary: Cannot parse pure/const/immutable functions with
inferred return type
   Product: D
   Version: 2.031
  Platform: All
OS/Version: All
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au


--- Comment #0 from Don clugd...@yahoo.com.au 2009-10-02 00:07:23 PDT ---
This bug was originally reported as part of bug 3174.

int goo(int i) pure { return i; } // OK
auto foo(int i) pure { return i; } // Can't parse

class A {
auto hoo(int i) pure  { return i; }  // can't parse
const boo(int i) const { return i; }  // can't parse
auto coo(int i) const { return i; }  // can't parse
auto doo(int i) immutable { return i; }  // can't parse
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3356] Make pure functions require immutable parameters

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3356



--- Comment #3 from Don clugd...@yahoo.com.au 2009-10-02 08:03:51 PDT ---
(In reply to comment #2)
 (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?

If you pass it the same *values*, you get the same results.

  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.

You don't need immutability in this case.
foo(a) cannot change a, because foo is pure. There is nothing else in the
expression which uses a. Therefore a does not change during the expression.
(I'm assuming a is not shared). Therefore both calls to foo(a) have the same
parameters, and the transformation foo(a) + foo(a) --- 2*foo(a) is legal.

As soon as you have an assignment, or a call to an impure function, you can't
do this any more. But if a is immutable, you have a much stronger guarantee.

 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).

Caching can only occur if all parameters passed to the function are the same.
If the parameters are references, you need to ensure the value being referenced
has not changed. Which is trivial if it's an immutable reference, but that's
not the _only_ case where it is true.

This is just an argument that const references _could_ be allowable in pure
functions. But after all that, the spec currently says that parameters have to
be implicitly immutable! So you can just change this to an accepts-invalid bug.
...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3361] New: code in std.zlib concatenates void[] arrays

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3361

   Summary: code in std.zlib concatenates void[] arrays
   Product: D
   Version: 1.045
  Platform: All
OS/Version: All
Status: NEW
  Severity: critical
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: thecybersha...@gmail.com


--- Comment #0 from Vladimir thecybersha...@gmail.com 2009-10-02 18:39:32 PDT 
---
Created an attachment (id=468)
proposed patch

In several places, the code in the std.zlib concatenates void[] arrays. This
causes allocation of data incorrectly marked as possibly containing pointers.
This bug is the main source of severe memory leaks in my application, thus it
is marked as critical.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---