[Issue 1715] Template specialization checks for equality rather than convertibility
http://d.puremagic.com/issues/show_bug.cgi?id=1715 Mike Linford mike.linf...@gmail.com changed: What|Removed |Added CC||mike.linf...@gmail.com Resolution|FIXED |INVALID --- Comment #3 from Mike Linford mike.linf...@gmail.com 2010-09-15 23:52:54 PDT --- (In reply to comment #2) http://www.dsource.org/projects/dmd/changeset/675 DMD 1.063 gives the same results for the given example and an example in my personal code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1715] Template specialization checks for equality rather than convertibility
http://d.puremagic.com/issues/show_bug.cgi?id=1715 Don clugd...@yahoo.com.au changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #4 from Don clugd...@yahoo.com.au 2010-09-16 00:09:24 PDT --- (In reply to comment #3) (In reply to comment #2) http://www.dsource.org/projects/dmd/changeset/675 DMD 1.063 gives the same results for the given example and an example in my personal code. Yes, of course. Why did you mark this as invalid The bug is definitely valid, and it's fixed in the upcoming beta. Please don't do this sort of thing again. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
http://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #31 from Trass3r mrmoc...@gmx.de 2010-09-16 05:07:27 PDT --- Note that ddmd has custom working stack trace code for windoze. Maybe this could help in some way. http://dsource.org/projects/ddmd -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4290] 'Fragile' opCmp/toHash signature errors
http://d.puremagic.com/issues/show_bug.cgi?id=4290 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2010-09-16 06:10:07 PDT --- Some more info about how the runtime deals with struct polymorphism and opCmp and toHash etc. In TypeInfo_Struct, there are the following function pointers: http://www.dsource.org/projects/druntime/browser/trunk/src/object_.d?rev=376#L930 The compiler sets these if you define the appropriate functions with the correct signatures. Then the runtime uses the TypeInfo.compare function to compare two values, or TypeInfo.getHash. The TypeInfo_Struct overrides these functions to check if those function pointers are valid, and if so, call them to compare two values. Otherwise, it does a bit-compare. Any runtime function that uses these functions (including array sort) will be affected. I disagree that the compiler should reject opCmp if it doesn't match the special signature, opCmp is simply a function. There are valid uses of opCmp that do not match the signature. For example, the compiler currently requires struct opEquals to have a signature of bool opEquals(ref const(T) other) const Which means you can't compare two rvalues (bug already filed). This is the mess that will occur if you start requiring special signatures for all the others. However, I think it would be good to add an attribute indicating that the compiler *should* reject the function if it doesn't match, as bearophile suggests. However, I think it should be an @attribute, not a keyword. My suggestion is @typeinfo to signify that this function belongs in the typeinfo. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1715] Template specialization checks for equality rather than convertibility
http://d.puremagic.com/issues/show_bug.cgi?id=1715 --- Comment #5 from Mike Linford mike.linf...@gmail.com 2010-09-16 09:34:29 PDT --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) http://www.dsource.org/projects/dmd/changeset/675 DMD 1.063 gives the same results for the given example and an example in my personal code. Yes, of course. Why did you mark this as invalid The bug is definitely valid, and it's fixed in the upcoming beta. Please don't do this sort of thing again. I guess I'm confused. It's claimed that the bug was resolved, but the latest version has the bug. Since the latest version in fact hasn't resolved the bug, doesn't that mean that the resolution was invalid? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #80 from nfx...@gmail.com 2010-09-16 11:26:43 PDT --- By the way, if the patch is going to be accepted, it would probably be good to get rid of the NO_SCAN flags. Instead, NO_SCAN should be detected by examining the PointerMap. A PointerMap with length 0 could take over the NO_SCAN meaning. E.g.: Old code: bool is_NO_SCAN = !(typeinfo.flags() 1); New code: bool is_NO_SCAN = typeinfo.pointermap().bits.length == 0; Then you don't need to provide/pass around the TypeInfo.flags() anymore. Would get rid of some uglyness. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4875] Allow struct initialization with constructor
http://d.puremagic.com/issues/show_bug.cgi?id=4875
--- Comment #4 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-09-16
15:36:08 PDT ---
(In reply to comment #1)
You may write this:
class File {
HANDLE Handle = HANDLE(5);
}
Hmm... giving it another thought, forcing explicit constructor syntax can be
ok: it makes things explicit and with proper OO wrapping doesn't require big
changes.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4290] 'Fragile' opCmp/toHash signature errors
http://d.puremagic.com/issues/show_bug.cgi?id=4290 --- Comment #3 from bearophile_h...@eml.cc 2010-09-16 17:21:12 PDT --- Answer to comment2: I understand what you say only partially. In my opinion silently ignoring the opCmp() and toHash() like in my first example is not acceptable for the D language (that was a bug in my code). The general design of D is to perform safe things on default, and unsafe on request. And here the safer thing is to perform the conformance tests on default and disable them on request. I agree that an attribute is better here. So a @notypeinfo seems better, if it's implementable and useful. I don't like the @typeinfo/@notypeinfo names a lot because they look too much tied to the underlying implementation, instead to their true semantic meaning/purpose. In LDC there is pragma(no_typeinfo): http://www.dsource.org/projects/ldc/wiki/Docs#no_typeinfo So I think it's better to find a different name for the attribute, different from @notypeinfo. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4877] New: Hole in Const System: popFront()
http://d.puremagic.com/issues/show_bug.cgi?id=4877
Summary: Hole in Const System: popFront()
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha dsim...@yahoo.com 2010-09-16 17:38:03 PDT ---
Apparently using ref array parameters/implicit conversions gets around const in
this example.
void popFront(T)(ref T[] arr) {
arr = arr[1..$];
}
void main() {
immutable arr = [1,2,3,4,5].idup;
arr.popFront();
assert(arr == [2,3,4,5]); // PASSES
}
Please take your time fixing this, though, as much of std.range relies on this
bug to work correctly with const/immutable arrays.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4579] std.typecons.Tuple syntax unpacking sugar
http://d.puremagic.com/issues/show_bug.cgi?id=4579
--- Comment #1 from bearophile_h...@eml.cc 2010-09-16 19:24:57 PDT ---
'auto' too may be supported:
void main() {
(auto fc, auto fa, auto fm) = getTimes(filename);
}
Or even:
void main() {
auto (fc, fa, fm) = getTimes(filename);
}
An unpacking syntax for Tuples is useful to replace the very similar zip() and
lockstep():
import std.algorithm, std.stdio, std.range;
void main() {
foreach (p; zip([1, 2, 3], abcd))
writeln(p._0, , p.length, , p._1);
writeln();
foreach (i, a, b; lockstep([1, 2, 3], abcd))
writeln(i, , a, , b);
}
with a single zip() that may be used for both situations:
import std.algorithm, std.stdio, std.range;
void main() {
foreach (p; zip([1, 2, 3], abcd))
writeln(p[0], , p[1]);
writeln();
foreach ((a, b); zip([1, 2, 3], abcd))
writeln(a, , b);
}
As in Python:
for p in zip([1, 2, 3], abcd):
print p[0], p[1]
print
for (a, b) in zip([1, 2, 3], abcd):
print a, b
(The zip() is a very commonly useful higher order function.)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
