[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)
http://d.puremagic.com/issues/show_bug.cgi?id=7135 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #10 from Kenji Hara k.hara...@gmail.com 2013-05-21 02:47:44 PDT --- I close this as resolved invalid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)
http://d.puremagic.com/issues/show_bug.cgi?id=7135
--- Comment #9 from Kenji Hara k.hara...@gmail.com 2012-03-13 20:50:21 PDT ---
(In reply to comment #8)
Note: Unfortunately, current dmd does not support parameter type inference +
type-safe variadisc like follows.
//delegate (self, args...) {...}
//(self, args...) {...}
I've filed bug 7705 to allow such lambda syntax, and posted a pull request to
fix it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)
http://d.puremagic.com/issues/show_bug.cgi?id=7135
--- Comment #8 from Kenji Hara k.hara...@gmail.com 2012-01-01 05:56:47 PST ---
(In reply to comment #7)
One more thing - the example in the book reads:
obj.addMethod(sayHello,
Variant(Dynamic, Variant[]...) {
writeln(Hello, world!);
return Variant();
});
That doesn't work. The compilable version reads:
obj.addMethod(sayHello,
delegate Variant(Dynamic, Variant[]...) {
writeln(Hello, world!);
return Variant();
});
Can we arrange things such that the delegate or function keywords aren't
require in the literal definition?
From past, omission of delegate keyword + specification of return type has
been wrong syntax. So Variant(Dynamic, Varinat[]...) { ... } couldn't compile.
And recent commit
https://github.com/D-Programming-Language/dmd/commit/c50eb5f5726a65efa1224ff0f0fd60acbb6e3027
has been disallowed optional parameter names, because of parameter type
inference.
From these matters, current TDPL code never become valid.
Today, following literal notations has been allowed with current dmd.
delegate Variant(Dynamic self, Variant[] args...) {...}
delegate (Dynamic self, Variant[] args...) {...}
(Dynamic self, Variant[] args...) {...}
Note: Unfortunately, current dmd does not support parameter type inference +
type-safe variadisc like follows.
//delegate (self, args...) {...}
//(self, args...) {...}
Because args could have three kind of infer targets.
T[N] args...// T is the element type of args
T[] args... // T is the element type of args
T args... // T is class type, and args is translated to new T(args)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)
http://d.puremagic.com/issues/show_bug.cgi?id=7135
--- Comment #2 from Andrei Alexandrescu and...@metalanguage.com 2011-12-31
00:40:00 PST ---
(In reply to comment #1)
This is not the delegate literal type deduction problem.
It is a trivial mismatching of delegate types.
This is the reduced code to explain the problem.
struct Variant {}
class Dynamic {}
alias Variant delegate(Dynamic self, Variant[] args...) DynMethod;
void main()
{
DynMethod dg = delegate Variant(Dynamic, Variant[]) {
return Variant();
};
}
Output:
test.d(6): Error: cannot implicitly convert expression (__dgliteral1) of type
Variant delegate(Dynamic _param_0, Variant[] _param_1) pure nthrow @safe to
Variant delegate(Dynamic self, Variant[] args...)
DynMethod has typesafe variadic parameter, but literal doesn't have.
So this is a bug of TDPL sample code, not compiler's.
I think (and perhaps I'm wrong) that the signature with ... and the one without
must be equivalent. The ... makes a difference only in the call syntax, but in
fact still passes an array. (Note that the variadics ending with T[] param...
are not unsafe C-style variadics.) Please advise - thanks!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)
http://d.puremagic.com/issues/show_bug.cgi?id=7135 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2011-12-31 01:01:24 PST --- (In reply to comment #2) I think (and perhaps I'm wrong) that the signature with ... and the one without must be equivalent. The ... makes a difference only in the call syntax, but in fact still passes an array. (Note that the variadics ending with T[] param... are not unsafe C-style variadics.) Please advise - thanks! Hmm, current compiler always raise an error against the difference of variadic argument kind (non-variarics vs typesafe-variadics vs C-style variadics). But, from http://d-programming-language.org/abi.html The variadic part is converted to a dynamic array and the rest is the same as for non-variadic functions. So, in ABI layer, (..., T[]) and (..., T[]...) might be same... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)
http://d.puremagic.com/issues/show_bug.cgi?id=7135
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #4 from Don clugd...@yahoo.com.au 2011-12-31 03:12:50 PST ---
(In reply to comment #3)
(In reply to comment #2)
I think (and perhaps I'm wrong) that the signature with ... and the one
without
must be equivalent. The ... makes a difference only in the call syntax, but
in
fact still passes an array. (Note that the variadics ending with T[]
param...
are not unsafe C-style variadics.) Please advise - thanks!
Hmm, current compiler always raise an error against the difference of variadic
argument kind (non-variarics vs typesafe-variadics vs C-style variadics).
But, from http://d-programming-language.org/abi.html
The variadic part is converted to a dynamic array and the rest is the same
as for non-variadic functions.
So, in ABI layer, (..., T[]) and (..., T[]...) might be same...
I don't think so. One difference is visible in declaration.html (there may be
other). It says:
An implementation may construct the object or array instance on the stack.
Therefore, it is an error to refer to that instance after the variadic function
has returned:
int[] test(int[] a ...) {
return a; // error, array contents invalid after return
}
So, it would be legal to call the delegate with the Variant[]... stored on the
stack. But it would fail.
It might be OK to assign a (Variant[]...) function to a (Variant[]) delegate,
but I'm pretty sure the other direction doesn't work.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)
http://d.puremagic.com/issues/show_bug.cgi?id=7135
timon.g...@gmx.ch changed:
What|Removed |Added
CC||timon.g...@gmx.ch
--- Comment #5 from timon.g...@gmx.ch 2011-12-31 07:32:53 PST ---
(In reply to comment #4)
(In reply to comment #3)
(In reply to comment #2)
I think (and perhaps I'm wrong) that the signature with ... and the one
without
must be equivalent. The ... makes a difference only in the call syntax,
but in
fact still passes an array. (Note that the variadics ending with T[]
param...
are not unsafe C-style variadics.) Please advise - thanks!
Hmm, current compiler always raise an error against the difference of
variadic
argument kind (non-variarics vs typesafe-variadics vs C-style variadics).
But, from http://d-programming-language.org/abi.html
The variadic part is converted to a dynamic array and the rest is the
same as for non-variadic functions.
So, in ABI layer, (..., T[]) and (..., T[]...) might be same...
I don't think so. One difference is visible in declaration.html (there may be
other). It says:
An implementation may construct the object or array instance on the stack.
Therefore, it is an error to refer to that instance after the variadic
function
has returned:
int[] test(int[] a ...) {
return a; // error, array contents invalid after return
}
So, it would be legal to call the delegate with the Variant[]... stored on the
stack. But it would fail.
It might be OK to assign a (Variant[]...) function to a (Variant[]) delegate,
but I'm pretty sure the other direction doesn't work.
It should be OK to assign (scope Variant[]) to (Variant[]...).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)
http://d.puremagic.com/issues/show_bug.cgi?id=7135
Andrei Alexandrescu and...@metalanguage.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Comment #6 from Andrei Alexandrescu and...@metalanguage.com 2011-12-31
08:43:40 PST ---
OK, it looks like this is safe to close now. I compiled a slightly modified
version. There was a bug elsewhere, the line
Variant opDispatch(string m, Args)(Args args...) {
should be
Variant opDispatch(string m, Args...)(Args args) {
Also, the signature of the delegate should contain ..., i.e. replace
delegate Variant(Dynamic, Variant[]) {
with
delegate Variant(Dynamic, Variant[]...) {
The working code is:
module test;// Context begin
#line 1369 0900-operators.tex
import std.variant;
alias Variant delegate(Dynamic self, Variant[] args...) DynMethod;
// Context end
// Context begin
#line 1383 0900-operators.tex
class Dynamic {
private DynMethod[string] methods;
void addMethod(string name, DynMethod m) {
methods[name] = m;
}
void removeMethod(string name) {
methods.remove(name);
}
// Dispatch dynamically on method
Variant call(string methodName, Variant[] args...) {
return methods[methodName](this, args);
}
// Provide syntactic sugar with opDispatch
Variant opDispatch(string m, Args...)(Args args) {
Variant[] packedArgs = new Variant[args.length];
foreach (i, arg; args) {
packedArgs[i] = Variant(arg);
}
return call(m, args);
}
}
// Context end
#line 1409 0900-operators.tex
unittest {
import std.stdio;
auto obj = new Dynamic;
obj.addMethod(sayHello,
delegate Variant(Dynamic, Variant[]...) {
writeln(Hello, world!);
return Variant();
});
obj.sayHello(); // Prints Hello, world!
}
void main(){}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)
http://d.puremagic.com/issues/show_bug.cgi?id=7135
Andrei Alexandrescu and...@metalanguage.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #7 from Andrei Alexandrescu and...@metalanguage.com 2011-12-31
10:32:43 PST ---
One more thing - the example in the book reads:
obj.addMethod(sayHello,
Variant(Dynamic, Variant[]...) {
writeln(Hello, world!);
return Variant();
});
That doesn't work. The compilable version reads:
obj.addMethod(sayHello,
delegate Variant(Dynamic, Variant[]...) {
writeln(Hello, world!);
return Variant();
});
Can we arrange things such that the delegate or function keywords aren't
require in the literal definition?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)
http://d.puremagic.com/issues/show_bug.cgi?id=7135
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-12-30 23:28:51 PST ---
This is not the delegate literal type deduction problem.
It is a trivial mismatching of delegate types.
This is the reduced code to explain the problem.
struct Variant {}
class Dynamic {}
alias Variant delegate(Dynamic self, Variant[] args...) DynMethod;
void main()
{
DynMethod dg = delegate Variant(Dynamic, Variant[]) {
return Variant();
};
}
Output:
test.d(6): Error: cannot implicitly convert expression (__dgliteral1) of type
Variant delegate(Dynamic _param_0, Variant[] _param_1) pure nthrow @safe to
Variant delegate(Dynamic self, Variant[] args...)
DynMethod has typesafe variadic parameter, but literal doesn't have.
So this is a bug of TDPL sample code, not compiler's.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
