Bug 8402 – Lambda argument's default value is not taken into account
Status
RESOLVED
Resolution
DUPLICATE
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-07-20T05:33:00Z
Last change time
2012-08-04T10:12:29Z
Assigned to
nobody
Creator
kolos80
Comments
Comment #0 by kolos80 — 2012-07-20T05:33:24Z
The following code does not compile (x.d):
void main()
{
auto fn = (int x = 0) => x + 1;
fn();
}
with message: "x.d(4): Error: expected 1 function arguments, not 0"
However, calling fn() with an explicit argument works fine as usual.
Comment #1 by issues.dlang — 2012-07-20T10:27:41Z
Default arguments with lambda functions don't really make sense given that they're generally only used in one place, that default arguments are _not_ part of the type (they're just inserted at the call site), and that there's no way for lambdas or function pointers to carry default arguments with them. So, the fact that it doesn't compile is a _good_ thing, though it really should give an error for giving a default argument and not just an error at the call site.
This is related to bug# 3646, but I'm not sure if it's strictly speaking a duplicate or not.
Comment #2 by exetoc — 2012-08-02T14:27:43Z
This seems to be relevant:
void function(int i = 0) f = (int i){};
void delegate(int i = 0) g = (int i){};
void main()
{
f();
g();
}
The error message is: "Error expected 1 function arguments, not 0", for both f and g.
(In reply to comment #1)
> Default arguments with lambda functions don't really make sense given that
> they're generally only used in one place, that default arguments are _not_ part
> of the type (they're just inserted at the call site), and that there's no way
> for lambdas or function pointers to carry default arguments with them. So, the
> fact that it doesn't compile is a _good_ thing, though it really should give an
> error for giving a default argument and not just an error at the call site.
>
> This is related to bug# 3646, but I'm not sure if it's strictly speaking a
> duplicate or not.
It did work in 2.059, which was nice, because it allowed libraries like Derelict to provide bindings for C++ libraries like FreeImage, without having to modify the interface in order to take into account potential default arguments which, as of 2.060, isn't the case anymore. Did this old behaviour have any negative effects at all?
Comment #3 by timon.gehr — 2012-08-02T17:36:56Z
(In reply to comment #2)
> Did this old behaviour have any negative effects at all?
Probably the feature was there by mistake. It was implemented incorrectly. I
think just associating the default arguments with the variable declaration might
work if something like it should be supported.
Comment #4 by exetoc — 2012-08-02T20:04:56Z
I was referring to variables (and not literals) in the latter part of my comment, whereas you probably didn't. If that is indeed the case, then disregard what I said.
Comment #5 by k.hara.pg — 2012-08-04T10:11:15Z
(In reply to comment #0)
> The following code does not compile (x.d):
>
> void main()
> {
> auto fn = (int x = 0) => x + 1;
> fn();
> }
>
> with message: "x.d(4): Error: expected 1 function arguments, not 0"
> However, calling fn() with an explicit argument works fine as usual.
The function pointer `fn` is not a lambda itself, so cannot have default argument.
If it is allowed:
auto fn = (int x = 0) => x + 1;
fn(); // returns 1
fn = (int x = 1) => x + 1;
fn(); // returns 1 or 2?
What is returned by the 2nd call of fn? I cannot imagine it.
Comment #6 by k.hara.pg — 2012-08-04T10:12:29Z
This issue is a part of bug 3866.
*** This issue has been marked as a duplicate of issue 3866 ***