digitalmars.D.bugs - [Issue 2832] New: pure function too pure
- d-bugmail puremagic.com (22/22) Apr 11 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2832
- d-bugmail puremagic.com (19/19) Jul 03 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2832
- d-bugmail puremagic.com (17/17) Oct 13 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2832
- d-bugmail puremagic.com (14/24) Oct 13 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2832
- d-bugmail puremagic.com (20/29) Oct 13 2009 But the passed-by-value parts of the arguments are copied and consequent...
- d-bugmail puremagic.com (21/21) Dec 11 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2832
- d-bugmail puremagic.com (10/10) Aug 15 2010 http://d.puremagic.com/issues/show_bug.cgi?id=2832
- d-bugmail puremagic.com (23/23) Sep 22 2010 http://d.puremagic.com/issues/show_bug.cgi?id=2832
- d-bugmail puremagic.com (7/7) Sep 22 2010 http://d.puremagic.com/issues/show_bug.cgi?id=2832
- d-bugmail puremagic.com (15/15) Nov 16 2010 http://d.puremagic.com/issues/show_bug.cgi?id=2832
http://d.puremagic.com/issues/show_bug.cgi?id=2832 Summary: pure function too pure Product: D Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: andrei metalanguage.com pure int fun(int d, int divisor) { if (d < 0) d -= divisor - 1; return d / divisor; } This doesn't compile because d is assumed to be constant. It doesn't have to because it's a private copy of the function. Beware when fixing this - any indirectly-referenced data is not part of function's private state. --
Apr 11 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2832 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au Comment: Allowing this would mean that nested pure functions would no longer be able to use the parameters from the enclosing function. pure int fun(int d, int divisor) { int gun() pure { return d+1; } // would be illegal, since 'fun' could modify d. return gun() + d / divisor; } Which in turn would mean that nested pure functions would become quite useless. So there's a price to pay. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 03 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2832 Max Samukha <samukha voliacable.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |samukha voliacable.com PDT --- Instead of introducing another inconsistency into the language for the not-so-common case, you could take the opposite route: pure int fun(int d, int divisor) { immutable c = d; int gun() pure { return c + 1; } return gun() + d / divisor; } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 13 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2832Instead of introducing another inconsistency into the language for the not-so-common case, you could take the opposite route: pure int fun(int d, int divisor) { immutable c = d; int gun() pure { return c + 1; } return gun() + d / divisor; }I think the existing behaviour -- that you cannot change any of the parameters in a pure function -- is simple and intuitive: pure functions can only modify variables which they created themselves. A rule that pure nested functions can use indirectly-referenced data, but cannot use parameters which are passed by value, just seems complicated. Especially, in the case where a parameter contains a reference to other data, it seems folly to be allowed to change part of the parameter, but not all of it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 13 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2832 PDT ---I think the existing behaviour -- that you cannot change any of the parameters in a pure function -- is simple and intuitive: pure functions can only modify variables which they created themselves.But the passed-by-value parts of the arguments are copied and consequently can be qualified as "variables which they created themselves".A rule that pure nested functions can use indirectly-referenced data, but cannot use parameters which are passed by value, just seems complicated.I don't think it is too complicated. It can be trivially done like this: pure int foo(in int d, ...) { // now we should be able to use d in pure nested functions because it is // guaranteed to not change during the function call. }Especially, in the case where a parameter contains a reference to other data, it seems folly to be allowed to change part of the parameter, but not all of it.I am not sure. For example, it seems to be fairly intuitive to be able to rebind a string parameter, though changing the referenced part of it is not allowed. I would agree if D's function parameters behaved like aliases to the arguments, but they are more like the function's local variables, which arguments are assigned to. Now that I am trying to purify some functions (most of which have no nested functions) I need to add the useless temporaries to make them compile :( -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 13 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2832 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com Severity|normal |enhancement 23:30:21 PST --- This would reintroduce "tail-const" for the parameters, something that we tried hard to make work and failed. I'd rather just leave the parameters const. If you have to make a mutable copy, as in: pure int fun(int d, int divisor) { auto x = d; if (x < 0) x -= divisor - 1; return x / divisor; } that isn't much of a burden, and the compiler will optimize the extra copy away anyway. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 11 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2832 David Simcha <dsimcha yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsimcha yahoo.com *** Issue 4630 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 15 2010
http://d.puremagic.com/issues/show_bug.cgi?id=2832 Tomash Brechko <tomash.brechko gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomash.brechko gmail.com 07:39:43 PDT --- Note that (with dmd 2.049) pure int f(int i) { return ++i; } doesn't compile, yet pure auto f(int i) { return ++i; } does work (int return type is replaced with auto). Also http://www.digitalmars.com/d/2.0/function.html section "Pure Functions" gives an example of assignment to parameter, i = y; // ok, reading immutable global state -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 22 2010
http://d.puremagic.com/issues/show_bug.cgi?id=2832 08:05:37 PDT --- Created separate issue http://d.puremagic.com/issues/show_bug.cgi?id=4915 for "int -> auto", as auto return type escapes pure completely. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 22 2010
http://d.puremagic.com/issues/show_bug.cgi?id=2832 Jesse Phillips <Jesse.K.Phillips+D gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |Jesse.K.Phillips+D gmail.co | |m Resolution| |FIXED 13:19:39 PST --- In the recent update of relaxed purity, this code now compiles. However I believe this is a weakly pure function as a strongly pure function requires its parameters to be immutable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 16 2010