[Issue 7207] Explicit cast should resolve lambda type
http://d.puremagic.com/issues/show_bug.cgi?id=7207 Kenji Hara changed: What|Removed |Added Keywords||patch, rejects-valid --- Comment #1 from Kenji Hara 2012-01-02 22:53:39 PST --- https://github.com/D-Programming-Language/dmd/pull/593 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7208] Unique arrays should be covariant
http://d.puremagic.com/issues/show_bug.cgi?id=7208 --- Comment #2 from timon.g...@gmx.ch 2012-01-02 22:14:18 PST --- No. There is no issue if the array is provable unique. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7208] Unique arrays should be covariant
http://d.puremagic.com/issues/show_bug.cgi?id=7208 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis 2012-01-02 22:12:49 PST --- Wouldn't this just reintroduce bug# 2095? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7208] New: Unique arrays should be covariant
http://d.puremagic.com/issues/show_bug.cgi?id=7208
Summary: Unique arrays should be covariant
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-01-02 22:02:21 PST ---
class A{}
void foo(Object[]){}
A[] bar()pure{return new A[16];}
void main(){
foo([new A]); // error
foo(new A[16]); // error
foo(bar()); // error
}
The code should compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7203] Method pointer types differ depending on context
http://d.puremagic.com/issues/show_bug.cgi?id=7203
Kenji Hara changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Comment #1 from Kenji Hara 2012-01-02 21:48:08 PST ---
In non-static member function of A, A.foo is implicitly translated to this.foo.
So in function foo, typeof(&A.foo) == typeof(this.foo) and it is delegate type.
class A {
void foo() {
A.foo(); // recursive call
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7207] New: Explicit cast should resolve lambda type
http://d.puremagic.com/issues/show_bug.cgi?id=7207 Summary: Explicit cast should resolve lambda type Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: timon.g...@gmx.ch --- Comment #0 from timon.g...@gmx.ch 2012-01-02 21:48:52 PST --- Tested with DMD 2.058head. auto dg = cast(int function(int))(a)=>a; Error: cannot cast __lambda2 The code should compile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7196] Unfair function address overload resolution
http://d.puremagic.com/issues/show_bug.cgi?id=7196
--- Comment #5 from Kenji Hara 2012-01-02 18:18:56 PST ---
(In reply to comment #4)
> If the compiler rewrites (&foo)(arguments...) to foo(arguments...), is it now
> able to inline delegates that are called directly like for example {x++;}() ?
Sorry, I'm not sure the meaning of 'inline'.
If you means 'optimizing', I don't know direct called delegate would be inlined
or not...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7202] Hole in type system still present for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=7202 Kenji Hara changed: What|Removed |Added Keywords||patch --- Comment #1 from Kenji Hara 2012-01-02 18:13:57 PST --- Will be fixed by my patch: https://github.com/D-Programming-Language/dmd/pull/558 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #8 from Kenji Hara 2012-01-02 16:59:46 PST --- (In reply to comment #6) > Ok, I understand. > > There are already a number of situation where the decision Type/Variable is > deferred to the semantic phase. Would it be possible to do the same here? > > If not, I think the same syntax for delegate literals should be forbidden for > built-in types for consistency. It's a small, but good improvement for consistent. I'll post a patch to fix it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7201] Lambda template assignment to variable
http://d.puremagic.com/issues/show_bug.cgi?id=7201 Kenji Hara changed: What|Removed |Added Keywords||patch --- Comment #1 from Kenji Hara 2012-01-02 16:54:53 PST --- I've already post a pull to support inference on AssignExp. https://github.com/D-Programming-Language/dmd/pull/593 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7206] Constructor from mixin does not conflict with other constructors
http://d.puremagic.com/issues/show_bug.cgi?id=7206 Trass3r changed: What|Removed |Added Keywords||diagnostic CC||mrmoc...@gmx.de --- Comment #3 from Trass3r 2012-01-02 14:42:28 PST --- Imho it isn't right though to silently accept this. There should at least be a warning that the code doesn't work as the general programmer would expect and maybe give a hint that you can achieve overload resolution with an additional alias. Otherwise it heavily depends on your code if you are lucky and get an error message like in http://d.puremagic.com/issues/show_bug.cgi?id=3332 or unexpected behavior. This is not limited to constructors. Overload resolution in general isn't easily possible. I have to resort to ugly string mixins just because of this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7206] Constructor from mixin does not conflict with other constructors
http://d.puremagic.com/issues/show_bug.cgi?id=7206 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #2 from timon.g...@gmx.ch 2012-01-02 14:24:56 PST --- This is by design: Spec: Mixin Scope The declarations in a mixin are 'imported' into the surrounding scope. If the name of a declaration in a mixin is the same as a declaration in the surrounding scope, the surrounding declaration overrides the mixin one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7206] Constructor from mixin does not conflict with other constructors
http://d.puremagic.com/issues/show_bug.cgi?id=7206 --- Comment #1 from Robert Clipsham 2012-01-02 22:13:34 GMT --- I forgot to mention, when ErrorsAsExpected is not defined, this prints b, the constructor from the mixin is disregarded. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7206] New: Constructor from mixin does not conflict with other constructors
http://d.puremagic.com/issues/show_bug.cgi?id=7206
Summary: Constructor from mixin does not conflict with other
constructors
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rob...@octarineparrot.com
--- Comment #0 from Robert Clipsham 2012-01-02
22:10:55 GMT ---
import std.stdio;
mixin template foo() {
this() {
writefln("a");
}
}
class A {
mixin foo!();
this() {
writefln("b");
}
version(ErrorsAsExpected) {
this() {
writefln("c");
}
}
}
void main() {
A a = new A;
}
When the above is compiled, no error is given, however when
-version=ErrorsAsExpected is given an error occurs. Tested with dmd 2.057.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7205] New: Function attribute inference fails in case of mutual dependencies
http://d.puremagic.com/issues/show_bug.cgi?id=7205
Summary: Function attribute inference fails in case of mutual
dependencies
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-01-02 14:07:28 PST ---
Tested with DMD 2.057.
void foo()(){bar();}
void bar()(){foo();}
void qux() @safe pure nothrow{foo();}
Error: pure function 'qux' cannot call impure function 'foo'
Error: safe function 'qux' cannot call system function 'foo'
Error: foo is not nothrow
Error: function tt.qux 'qux' is nothrow yet may throw
The code should compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 --- Comment #18 from Vladimir Panteleev 2012-01-02 13:32:01 PST --- (In reply to comment #17) > For part 1 (fastest possible 'chained' appender): Simply construct specifying > a > large number of elements. i.e. > auto app = Appender!string(4096); > FastestAppender7 seems to do something similar (enum MIN_SIZE = 4096;) The 4th one does that too, albeit implicitly. MIN_SIZE is half a page, but it will always allocate a little over that; which will cause the GC to return a whole page. MIN_SIZE was chosen to be the smallest size that results in an expandable allocation. Note that the 7th experiment is the least GC-friendly of the whole. > As for part 2 (fastest practical 'chained' appender) I haven't written it yet. > In essence you'd have two TLS variables, a scratch node and memory page and an > in use flag. Sounds like a nice idea. > I'm referring to the fact that ptr + i => cast(T*)(cast(size_t)ptr + > i*T.sizeof) and ptrA - ptrB => (cast(size_t)ptrA - cast(size_t)ptrB) / > T.sizeof. Which can lead to a subtle performance issues when T.sizeof != 1 or > a > power of 2. But, my first code review doesn't reveal any worrying usages in > the > primary code path; most cases of ptrA-ptrB seem to be behind rarely used if > conditionals. Yes, that was my point. Only one multiplication by T.sizeof and one branch are necessary on the hot path when appending a single item (I see that my code doesn't follow this due to its usage of slice copies). I wonder if putting the "cursorEnd > end" check inside the per-item loop in such cases would be faster - it would be exchanging a multiplication with a branch. > Regarding your previous assertion: > > 4) You can write a nextCapacity function with no branches > I'm having trouble finding this in the code. All I can find is: > > auto newCapacity = newSize < MIN_SIZE ? MIN_SIZE : newSize * 2; > > which contains a branch. (i.e. the ?: operator). The main idea is in fastappender2.d. The "if" at the start can be replaced with another bitwise or. It doesn't even matter, because that code will not be executed as often to make a significant difference; I stated it more as a curiosity. > Also, I know understand better what you meant by > > 1) Extra indirection levels are performance killers > Unfortunately, your attempt to reduce the number of indirections has broken > one > of the invariants of Appender; specifically that it is a reference type. > Putting cursors, etc. into the Appender struct will result in data stomping. I know, I said so in my answer to Andrei's comment. This is fine for my uses. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813
--- Comment #17 from Rob Jacques 2012-01-02 13:16:19 PST ---
> > That said, I did write a faster
> > chained appender for your benchmarks; however I did this by initializing the
> > appender with a page of memory, which definitely should not be the default
> > behavior. That said, one viable strategy for appender would be to keep 1
> > page
> > of memory around as a scratch pad.
>
> Can you elaborate on this (or share your code)?
For part 1 (fastest possible 'chained' appender): Simply construct specifying a
large number of elements. i.e.
auto app = Appender!string(4096);
FastestAppender7 seems to do something similar (enum MIN_SIZE = 4096;)
As for part 2 (fastest practical 'chained' appender) I haven't written it yet.
In essence you'd have two TLS variables, a scratch node and memory page and an
in use flag.
private static void* __Appender_scratch_node;
private static bool __Appender_scratch_in_use;
Appender(T) {...}
Then when appender is constructed instead of creating a new node and a little
bit of ram each time, a single node and 1 page of memory would be reused. The
boolean flag would prevent a second appender from reusing the same scratch pad;
(I figure 2+ appenders would be relatively rare). Then, when data is called a
single copy would be made of the correct length (Appending after data should
also be relatively rare).
> > > 5) It's better to store an "end" pointer than a "capacity" integer
> > I'll look into this, but this you can not make this judgment call based on
> > the
> > performance of a char appender. The issue is that anything with a power of 2
> > T.sizeof performs integer multiplication/division using shift operations
> > instead of the actual underlying instructions, both of which are very slow.
>
> I'm not following your explanation. I don't see how element size plays against
> my conclusion - in fact, as far as I can see, calculating a
> "position-after-append" pointer and comparing it to an "end" pointer is going
> to be faster, because you will need to update the position anyway.
I'm referring to the fact that ptr + i => cast(T*)(cast(size_t)ptr +
i*T.sizeof) and ptrA - ptrB => (cast(size_t)ptrA - cast(size_t)ptrB) /
T.sizeof. Which can lead to a subtle performance issues when T.sizeof != 1 or a
power of 2. But, my first code review doesn't reveal any worrying usages in the
primary code path; most cases of ptrA-ptrB seem to be behind rarely used if
conditionals.
P.S.
Regarding your previous assertion:
> 4) You can write a nextCapacity function with no branches
I'm having trouble finding this in the code. All I can find is:
auto newCapacity = newSize < MIN_SIZE ? MIN_SIZE : newSize * 2;
which contains a branch. (i.e. the ?: operator).
Also, I know understand better what you meant by
> 1) Extra indirection levels are performance killers
Unfortunately, your attempt to reduce the number of indirections has broken one
of the invariants of Appender; specifically that it is a reference type.
Putting cursors, etc. into the Appender struct will result in data stomping.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7204] New: [CTFE] Assertion failure when attempting to access function pointer of delegate
http://d.puremagic.com/issues/show_bug.cgi?id=7204
Summary: [CTFE] Assertion failure when attempting to access
function pointer of delegate
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rob...@octarineparrot.com
--- Comment #0 from Robert Clipsham 2012-01-02
20:40:18 GMT ---
auto foo()
{
void delegate() myDg;
return myDg.funcptr;
}
enum _ = foo();
This gives an assertion failure using dmd 2.057:
Assertion failed: (IsStackValueValid(newval)), function createStackValue, file
interpret.c, line 6262.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7203] New: Method pointer types differ depending on context
http://d.puremagic.com/issues/show_bug.cgi?id=7203
Summary: Method pointer types differ depending on context
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rob...@octarineparrot.com
--- Comment #0 from Robert Clipsham 2012-01-02
20:23:09 GMT ---
class A {
void foo() {
pragma(msg, typeof(&A.foo).stringof);
}
}
pragma(msg, typeof(&A.foo).stringof);
This produces:
void function()
void delegate()
However it should produce void function() in both cases.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 --- Comment #16 from Vladimir Panteleev 2012-01-02 12:10:18 PST --- (In reply to comment #15) > Vladimir, the code in > https://github.com/CyberShadow/ae/blob/master/utils/appender.d > seems to be under the MPL, which isn't Phobos compatible. What license is the > code in: > https://github.com/CyberShadow/DAppenderResearch > under? If it's not under a Boost compatible license, could you make it > available under one? Sure, consider my code in DAppenderResearch public domain. ae is mainly MPL because it was the least restrictive license other contributors agreed on. > That said, I did write a faster > chained appender for your benchmarks; however I did this by initializing the > appender with a page of memory, which definitely should not be the default > behavior. That said, one viable strategy for appender would be to keep 1 page > of memory around as a scratch pad. Can you elaborate on this (or share your code)? > > 5) It's better to store an "end" pointer than a "capacity" integer > I'll look into this, but this you can not make this judgment call based on the > performance of a char appender. The issue is that anything with a power of 2 > T.sizeof performs integer multiplication/division using shift operations > instead of the actual underlying instructions, both of which are very slow. I'm not following your explanation. I don't see how element size plays against my conclusion - in fact, as far as I can see, calculating a "position-after-append" pointer and comparing it to an "end" pointer is going to be faster, because you will need to update the position anyway. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 --- Comment #15 from Rob Jacques 2012-01-02 12:02:40 PST --- Vladimir, the code in https://github.com/CyberShadow/ae/blob/master/utils/appender.d seems to be under the MPL, which isn't Phobos compatible. What license is the code in: https://github.com/CyberShadow/DAppenderResearch under? If it's not under a Boost compatible license, could you make it available under one? Thanks for all this work. (In reply to comment #12) > 1) Extra indirection levels are performance killers I agree. > 2) I failed to create a chained appender (like the one in this patch) that was > faster than a copying one, for my test cases The primary purpose of a chained appender is to minimize memory leaks, memory usage and maximizing large scale performance. That said, I did write a faster chained appender for your benchmarks; however I did this by initializing the appender with a page of memory, which definitely should not be the default behavior. That said, one viable strategy for appender would be to keep 1 page of memory around as a scratch pad. > 3) At least on Windows and with short strings, simple slice copy trumps all > memcpy implementations I tried > 4) You can write a nextCapacity function with no branches Good to know. > 5) It's better to store an "end" pointer than a "capacity" integer I'll look into this, but this you can not make this judgment call based on the performance of a char appender. The issue is that anything with a power of 2 T.sizeof performs integer multiplication/division using shift operations instead of the actual underlying instructions, both of which are very slow. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7196] Unfair function address overload resolution
http://d.puremagic.com/issues/show_bug.cgi?id=7196
--- Comment #4 from timon.g...@gmx.ch 2012-01-02 11:47:18 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > This is strange - issue 52 is marked as fixed, so why does it still EVER
> > pick
> > the wrong instance?
>
> This problem is only when the caller of CallExp is AddrExp (== &foo).
> bug 51 is the problems on initializer and rhs of AssignExp.
>
> > Where does the spec address the meaning of &foo if there's more than one
> > function called foo in scope?
>
> In this case, CallExp can pick the original overload of foo in static.
> Therefore compiler should translate from (&foo)(arguments...) to
> foo(arguments...).
> Finally, the overload should be resolved.
If the compiler rewrites (&foo)(arguments...) to foo(arguments...), is it now
able to inline delegates that are called directly like for example {x++;}() ?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7202] New: Hole in type system still present for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=7202
Summary: Hole in type system still present for delegates
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-01-02 11:33:08 PST ---
For example:
void main() {
void delegate()@system x = {writeln("I am @system");};
void delegate()@safe y = {};
auto px = &x;
auto py = &y;
px = py; // accepts-invalid
*px = x;
y(); // "I am @system"
}
The equivalent example with function pointers already results in a compile
error.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7201] New: Lambda template assignment to variable
http://d.puremagic.com/issues/show_bug.cgi?id=7201
Summary: Lambda template assignment to variable
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-01-02 09:54:34 PST ---
In DMD 2.058head the compiler accepts a function template as argument for the
foo() function:
void foo(int function(int x) g) {}
void main() {
foo((x) => 0); // OK
}
So I think it should accept an assignment too:
void main() {
int function(int x) f;
f = (x) => 0; // Error
}
Currently it gives:
test.d(3): Error: __lambda4 has no value
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7200] New: Array append causes Access Violation with symbolic debug info
http://d.puremagic.com/issues/show_bug.cgi?id=7200
Summary: Array append causes Access Violation with symbolic
debug info
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-01-02 09:48:54 PST ---
import std.typecons: Tuple;
void main() {
alias Tuple!(int, int) Foo;
Foo[] a;
a ~= Foo(0, 0); // Access Violation
string[] b;
}
Compiling it with DMD 2.058head:
dmd -g test.d
gives an Access Violation at line 5 at runtime.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198
--- Comment #7 from Jacob Carlborg 2012-01-02 09:09:00 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (I don't actually know why we have unnamed parameters at all; most modern
> > > languages simply don't allow this. In addition, unused parameters in
> > > delegate/function literals/lambdas sort of seems to go against the entire
> > > idea
> > > with lambda functions, in the general case.)
> >
> > Useful situations for unnamed parameters:
> >
> > * Declaring a delegate type
> >
> > void delegate (int) dg;
>
> But that's a type signature, not a literal.
Oh, yeah, right.
> >
> > * Declaring a function/method without implementation
> >
> > void foo (int);
>
> This, on the other hand, I do not like. Without a parameter name, you have to
> look at the implementation to have a clue what it means. That makes the
> declaration (more or less) useless.
I've seen it a lot when declaring C functions. There won't be an implementation
(at least not in your code) and you're relying on the documentation for the C
library.
> >
> > * Overriding/implementing a method where a parameter isn't needed
> >
> > class Foo {
> > abstract void foo (int a);
> > }
> >
> > class Bar : Foo {
> > void foo (int) {}
> > }
> >
>
> Point taken, though naming it _ or similar usually works.
That will only work for one argument.
> >
> > These are the situations I see it as might being useful but I would say that
> > adding names to the parameters adds documentation and that's always a good
> > thing.
>
> Agreed.
Note that I'm not against this idea. Just pointing out how/when it can be used.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #6 from Rainer Schuetze 2012-01-02 07:44:36 PST --- Ok, I understand. There are already a number of situation where the decision Type/Variable is deferred to the semantic phase. Would it be possible to do the same here? If not, I think the same syntax for delegate literals should be forbidden for built-in types for consistency. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7199] New: std.string.indexof cannot be compiled with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=7199
Summary: std.string.indexof cannot be compiled with -inline
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze 2012-01-02 07:30:11
PST ---
With the latest version from github, this code fails to compile with "-inline":
module test;
import std.string;
int main()
{
string s = "abcd";
int index = indexOf(s, "b");
return index;
}
m:\s\d\rainers\phobos\std\algorithm.d(2970): Error: function
std.string.indexOf!
(char,char).indexOf.simpleMindedFind!(__lambda6,const(char)[],const(char)[]).sim
pleMindedFind is a nested function and cannot be accessed from main
This works with dmd 2.057 or without -inline.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198
--- Comment #5 from Alex R�nne Petersen 2012-01-02
06:41:35 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > (I don't actually know why we have unnamed parameters at all; most modern
> > languages simply don't allow this. In addition, unused parameters in
> > delegate/function literals/lambdas sort of seems to go against the entire
> > idea
> > with lambda functions, in the general case.)
>
> Useful situations for unnamed parameters:
>
> * Declaring a delegate type
>
> void delegate (int) dg;
But that's a type signature, not a literal.
>
> * Declaring a function/method without implementation
>
> void foo (int);
This, on the other hand, I do not like. Without a parameter name, you have to
look at the implementation to have a clue what it means. That makes the
declaration (more or less) useless.
>
> * Overriding/implementing a method where a parameter isn't needed
>
> class Foo {
> abstract void foo (int a);
> }
>
> class Bar : Foo {
> void foo (int) {}
> }
>
Point taken, though naming it _ or similar usually works.
>
> These are the situations I see it as might being useful but I would say that
> adding names to the parameters adds documentation and that's always a good
> thing.
Agreed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198
Jacob Carlborg changed:
What|Removed |Added
CC||d...@me.com
--- Comment #4 from Jacob Carlborg 2012-01-02 06:35:27 PST ---
(In reply to comment #3)
> (I don't actually know why we have unnamed parameters at all; most modern
> languages simply don't allow this. In addition, unused parameters in
> delegate/function literals/lambdas sort of seems to go against the entire idea
> with lambda functions, in the general case.)
Useful situations for unnamed parameters:
* Declaring a delegate type
void delegate (int) dg;
* Declaring a function/method without implementation
void foo (int);
* Overriding/implementing a method where a parameter isn't needed
class Foo {
abstract void foo (int a);
}
class Bar : Foo {
void foo (int) {}
}
These are the situations I see it as might being useful but I would say that
adding names to the parameters adds documentation and that's always a good
thing.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #3 from Alex R�nne Petersen 2012-01-02 05:46:26 PST --- (I don't actually know why we have unnamed parameters at all; most modern languages simply don't allow this. In addition, unused parameters in delegate/function literals/lambdas sort of seems to go against the entire idea with lambda functions, in the general case.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 Alex R�nne Petersen changed: What|Removed |Added CC||xtzgzo...@gmail.com --- Comment #2 from Alex R�nne Petersen 2012-01-02 05:40:07 PST --- Why not just disallow unnamed parameters entirely? Seems like cleaner language design to me. What we have now is clearly ambiguous and cannot be resolved, so... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #1 from Kenji Hara 2012-01-02 05:35:59 PST --- > I guess the trouble is that the delegate argument "Widget" is interpreted as a parameter name, not the type. Using "int" instead of "Widget" compiles. Yes, you're right. And that is inevitable side-effect of parameter type inference. Walter answered about the decision in https://github.com/D-Programming-Language/dmd/pull/588 . So this issue should be marked as 'resolved-invalid' or 'resolved-wontfix', IMO. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7198] New: Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198
Summary: Delegate literals with nameless arguments fail to
infer a type
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze 2012-01-02 05:07:52
PST ---
Maybe this is an expected side-effect of more magic with delegate type
inference, but the latest dmd version from github causes errors with this code:
module test;
class Widget {}
void main()
{
auto dg0 = delegate void(Widget w) { }; // OK
auto dg1 = delegate void(Widget) { }; // error
void delegate(Widget) dg2 = delegate void(Widget) { }; //OK
void delegate(Widget) dg3;
dg3 = delegate void(Widget) { foo(); }; //error
}
test.d(8): Error: cannot infer type from ambiguous function literal
__dgliteral2
test.d(8): Error: __dgliteral2 has no value
test.d(11): Error: __dgliteral6 has no value
This compiles with dmd 2.057.
I guess the trouble is that the delegate argument "Widget" is interpreted as a
parameter name, not the type. Using "int" instead of "Widget" compiles.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4349] Deprecate automatic case fallthrough
http://d.puremagic.com/issues/show_bug.cgi?id=4349
bearophile_h...@eml.cc changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Comment #7 from bearophile_h...@eml.cc 2012-01-02 04:35:19 PST ---
(In reply to comment #6)
> This one is ready to be closed, right?
I don't like a lot the presence of a special case to the D rule that implicit
fall-through is disallowed in D (this code compiles):
void main() {
int x;
switch (x) {
case 1: /* x++; break; */
case 2: break;
default: break;
}
}
But I presume you are right, so I close this issue.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7073] Parsing of class-returning varargs function inside module ctor fails
http://d.puremagic.com/issues/show_bug.cgi?id=7073 Kenji Hara changed: What|Removed |Added Keywords||patch, rejects-valid --- Comment #2 from Kenji Hara 2012-01-02 04:14:50 PST --- D2 patch: https://github.com/D-Programming-Language/dmd/pull/601 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7196] Unfair function address overload resolution
http://d.puremagic.com/issues/show_bug.cgi?id=7196 --- Comment #3 from Kenji Hara 2012-01-02 03:19:13 PST --- (In reply to comment #2) > This is strange - issue 52 is marked as fixed, so why does it still EVER pick > the wrong instance? This problem is only when the caller of CallExp is AddrExp (== &foo). bug 51 is the problems on initializer and rhs of AssignExp. > Where does the spec address the meaning of &foo if there's more than one > function called foo in scope? In this case, CallExp can pick the original overload of foo in static. Therefore compiler should translate from (&foo)(arguments...) to foo(arguments...). Finally, the overload should be resolved. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7196] Unfair function address overload resolution
http://d.puremagic.com/issues/show_bug.cgi?id=7196 Stewart Gordon changed: What|Removed |Added CC||s...@iname.com --- Comment #2 from Stewart Gordon 2012-01-02 02:43:35 PST --- This is strange - issue 52 is marked as fixed, so why does it still EVER pick the wrong instance? Where does the spec address the meaning of &foo if there's more than one function called foo in scope? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4976] Can't use auto on const member functions.
http://d.puremagic.com/issues/show_bug.cgi?id=4976 Kenji Hara changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #4 from Kenji Hara 2012-01-02 02:25:47 PST --- Fixed in 2.054. https://github.com/D-Programming-Language/dmd/commit/6a15077f8189e1ef203565edaebc766446aa105b -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7196] Unfair function address overload resolution
http://d.puremagic.com/issues/show_bug.cgi?id=7196 Kenji Hara changed: What|Removed |Added Keywords||patch, rejects-valid Platform|Other |All --- Comment #1 from Kenji Hara 2012-01-02 01:25:23 PST --- https://github.com/D-Programming-Language/dmd/pull/600 AddrExp that is yet not bounded into an variable should keep unresolved overload information. So the both lines should compile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7174] Cannot use property function call as static if condition
http://d.puremagic.com/issues/show_bug.cgi?id=7174 Kenji Hara changed: What|Removed |Added Keywords||patch, rejects-valid Platform|Other |All --- Comment #1 from Kenji Hara 2012-01-02 01:22:34 PST --- https://github.com/D-Programming-Language/dmd/pull/599 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7120] Scope Delegates + Delegate Literals
http://d.puremagic.com/issues/show_bug.cgi?id=7120 Kenji Hara changed: What|Removed |Added Keywords||patch --- Comment #1 from Kenji Hara 2012-01-02 01:22:04 PST --- https://github.com/D-Programming-Language/dmd/pull/598 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7106] DMD Segmentation faults!
http://d.puremagic.com/issues/show_bug.cgi?id=7106 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Kenji Hara 2012-01-02 00:50:51 PST --- In 2.057 and later, following errors are raised: test.d(17): Error: incompatible types for ((p) - (p)): 'const(Pa!(double))' and 'const(Pa!(double))' test.d(22): Error: template instance test.foo!(Pa,double) error instantiating Because, in Ma!T.opBinary(), return Ma(m); is not valid expression (it does not ignite copy construction). After fixing it to return Ma(); , the sample code compiles fine. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
