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=2832
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;
}
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









d-bugmail puremagic.com 