[Issue 8127] dmd link library paths not given precedence over gcc defaults
http://d.puremagic.com/issues/show_bug.cgi?id=8127 --- Comment #2 from github-bugzi...@puremagic.com 2012-05-23 23:13:51 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/4dbf21ec176de2e1d8e42a538173c4582a25f1c9 fix Issue 8127 - dmd link library paths not given precedence over gcc defaults https://github.com/D-Programming-Language/dmd/commit/e95ee9e91a5d0aea169e68fb84d0d92684d22258 Merge pull request #962 from belm0/linker_path_order fix Issue 8127 - dmd link library paths not given precedence over gcc defaults -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8133] regression(2.059): D shared lib on OSX fails in 2.059, worked in 2.058
http://d.puremagic.com/issues/show_bug.cgi?id=8133 --- Comment #4 from Jacob Carlborg d...@me.com 2012-05-23 23:23:08 PDT --- (In reply to comment #3) I see. Indeed the fix you had supplied did fix both Issue 7995 and this current Issue 8133 (I had pulled in the meantime the master which reverted to before your fix). It would be really great if Walter could accept your pull request once again as it is a real blocker not to be able to build shared libs. I also don't really understand his concern in his comment. Perhaps you could bug him again? A unittest with such test cases would prevent further regressions. I've done that. Apparently the exit status program was incorrect. I'll give it another shot. Also, I really think it should be made clear on the dlang website in release notes what is currently supported in each version. For example, diverse forums complain that support for shared libs on OSX is not working yet with the D runtime, but 2.058 or your fix seem to support those. No, shared libraries are still not completely supported on Posix. There's problem with module constructs, exception handling tables and TLS data. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8127] dmd link library paths not given precedence over gcc defaults
http://d.puremagic.com/issues/show_bug.cgi?id=8127 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2278] Guarantee alignment of stack-allocated variables on x86
http://d.puremagic.com/issues/show_bug.cgi?id=2278 Manu turkey...@gmail.com changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #9 from Manu turkey...@gmail.com 2012-05-24 03:08:55 PDT --- I'm at the point where I can't reasonably work around this issue anymore. It's not just for SSE (although that is one very important case), there are also structures that encapsulate SSE variables (16 byte), structures that must be L1 line aligned (64/128 bytes), structures that must be GPU page aligned (4k-ish), virtual page alignment, and occasionally other alignments are required (for instance, in one case an algorithms performance was near doubled by aligning to 256 bytes, and squatting a byte of data in the unused low bits of the pointer) Structure alignment is really really important, and it's very annoying to work-around (and often wastes memory in doing so) As we did with 256bit vectors, can we define the grammar for attributing a struct with an alignment? Then GDC/LDC can hook it straight up, and DMD can produce an unsupported message for the time being. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8139] New: Make objects really disposable by addition of Object finalized assertion
http://d.puremagic.com/issues/show_bug.cgi?id=8139 Summary: Make objects really disposable by addition of Object finalized assertion Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: contracts, diagnostic Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: verylonglogin@gmail.com --- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2012-05-24 14:39:44 MSD --- Original NG thread: True disposable objects (add Finalized! assertion) http://forum.dlang.org/thread/jo0p3a$aue$1...@digitalmars.com First message from NG thread: This idea is too obvious and I suppose I'm the only one not knowing it, but I have never seen it's implementation. Why? The idea: 1. `Object` class has hidden `isAlive` field which is true since construction and up to finalization. 2. Every method asserts that the object is alive first. 3. There is an `finalize` function that just rt_finalize an object in debug mode but can even free memory in release mode. Isn't it no-brainer? Isn't it the only way to debug manual memory management and shared resources without error-prone boilerplate? This is what I missed in C#, where I can dispose an object but I have to manually check the object isn't disposed every time I use it or in every it's method to find where I'm doing something with a disposed object by a mistake. IMHO finding using of dead references is almost as major as not allowing to free memory of alive objects (I mean GC), but GC is often implemented and dead references detection isn't. Strongly require your thoughts. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8139] Make objects really disposable by addition of Object finalized assertion
http://d.puremagic.com/issues/show_bug.cgi?id=8139
Alex R�nne Petersen a...@lycus.org changed:
What|Removed |Added
CC||a...@lycus.org
--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-05-24 12:46:56
CEST ---
The idea in and of itself is not bad. In fact, it would make debugging
wonderfully easy. My only concern is this: Object size. We already store two
words of memory in *every single object header*. This means 8 bytes on 32-bit
and 16 bytes on 64-bit.
Now suppose we added an extra bool field to Object. Not only would the compiler
have to be changed to align fields correctly, but it would also result in
objects eating 12 bytes on 32-bit and 24 bytes on 64-bit (simply because the GC
only power of two allocations or something along those lines).
Now, the memory concern is not a problem for a class like this:
class A
{
bool b;
short s;
}
Obviously we don't need word alignment here, and we could probably optimize
given that. But consider:
class B
{
A a;
}
Suddenly that bool field has to suck an entire machine word's worth of space
for 'a' to be aligned correctly.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8139] Make objects really disposable by addition of Object finalized assertion
http://d.puremagic.com/issues/show_bug.cgi?id=8139 --- Comment #2 from Denis Shelomovskij verylonglogin@gmail.com 2012-05-24 15:00:11 MSD --- (In reply to comment #1) Now suppose we added an extra bool field to Object. From Sean Kelly's reply at NG: rt_finalize currently nulls out the vtbl pointer, which can server as an isAlive flag if desired. Link: http://forum.dlang.org/thread/jo0p3a$aue$1...@digitalmars.com#post-mailman.323.1336157840.24740.digitalmars-d:40puremagic.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8139] Make objects really disposable by addition of Object finalized assertion
http://d.puremagic.com/issues/show_bug.cgi?id=8139 --- Comment #3 from Alex R�nne Petersen a...@lycus.org 2012-05-24 13:00:51 CEST --- In that case, I have no objections to doing this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8139] Make objects really disposable by addition of Object finalized assertion
http://d.puremagic.com/issues/show_bug.cgi?id=8139 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #4 from Jacob Carlborg d...@me.com 2012-05-24 05:10:01 PDT --- From Sean Kelly's reply at NG: rt_finalize currently nulls out the vtbl pointer, which can server as an isAlive flag if desired. Link: http://forum.dlang.org/thread/jo0p3a$aue$1...@digitalmars.com#post-mailman.323.1336157840.24740.digitalmars-d:40puremagic.com The vtbl is only needed for virtual methods. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8139] Make objects really disposable by addition of Object finalized assertion
http://d.puremagic.com/issues/show_bug.cgi?id=8139 --- Comment #5 from Alex R�nne Petersen a...@lycus.org 2012-05-24 14:11:06 CEST --- It's still set for all objects because it contains a pointer to type info. (The other machine word is the monitor.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8140] New: allow to catch exceptions by implemented interface
http://d.puremagic.com/issues/show_bug.cgi?id=8140
Summary: allow to catch exceptions by implemented interface
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: luka8...@owave.net
--- Comment #0 from luka8088 luka8...@owave.net 2012-05-24 05:22:09 PDT ---
Now we can only catch by class that is derived from Throwable. This prevents
logical generic *grouping* and catching by *group*. As discussed in #d on
freenode irc from 24-05-2012 13:20:00 to 24-05-2012 13:56:00.
For example:
// assume that IThrowable is in druntime
interface IMyException1: IThrowable {}
interface IMyException2: IThrowable {}
interface IMyException3: IThrowable {}
class MyException1: Exception, IMyException1 {}
class MyException2: Exception, IMyException1, IMyException2 {}
class MyException3: Exception, IMyException1 ,IMyException3 {}
class MyException4: Exception, IMyException3 {}
try {
throw new MyException2();
} catch (IMyException3) {
// catches MyException3 or MyException4
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #8 from Steven Schveighoffer schvei...@yahoo.com 2012-05-24 07:01:45 PDT --- (In reply to comment #4) FWIW, I'm all for making Errors actually fatal and terminating the runtime immediately, but then OutOfMemory*Error* HAS GOT TO GO. Then you could mark almost nothing as nothrow. I think OutOfMemory should be an error. If you want to override the behavior because you have special circumstances, that should be possible (i.e. somehow prevent out of memory error from being thrown, but instead handle the situation in a different way). What about an enhancement of adding GC.mallocNoError and friends which instead return null when a memory block is not available instead of throwing? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 jens.k.muel...@gmx.de changed: What|Removed |Added CC||jens.k.muel...@gmx.de --- Comment #9 from jens.k.muel...@gmx.de 2012-05-24 07:15:30 PDT --- I don't see why there should be no way to do some simple cleanup on an Error. Testing in contracts is useful and does no harm. Maybe Walter can give a concrete example where handling of Errors caused the program to be in a worse state compared to exit right away given the programmer had a solid understanding of what he was doing. Assuming I get an OutOfMemoryError having chances sending last words is useful. I fail to see how this can make it worse. It may be that he has seen to many misuses of handling errors. I would go with a C++ attitude: You can catch, scope guard, etc. any Throwable and even try to recover from Exceptions. But Errors are not meant to be recovered from. You have been warned. TDPL also says that it's okay to do some cleanup. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8098] Inner class method can modify outer's members regardless of constancy
http://d.puremagic.com/issues/show_bug.cgi?id=8098 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Platform|x86 |All OS/Version|Windows |All --- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-05-24 08:20:46 PDT --- https://github.com/D-Programming-Language/dmd/pull/964 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8090] ICE: Assertion failure: 'typen-deco' on line 1703 in file 'cast.c'
http://d.puremagic.com/issues/show_bug.cgi?id=8090 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||ice --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-05-24 09:02:47 PDT --- What version do you use? I think this is a dup of bug 8009 (It was a bug in 2.059, and is already fixed), because this ICE doesn't occur in git head. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 --- Comment #10 from Alex R�nne Petersen a...@lycus.org 2012-05-24 18:44:33 CEST --- (In reply to comment #8) (In reply to comment #4) FWIW, I'm all for making Errors actually fatal and terminating the runtime immediately, but then OutOfMemory*Error* HAS GOT TO GO. Then you could mark almost nothing as nothrow. True. I think OutOfMemory should be an error. If you want to override the behavior because you have special circumstances, that should be possible (i.e. somehow prevent out of memory error from being thrown, but instead handle the situation in a different way). What about an enhancement of adding GC.mallocNoError and friends which instead return null when a memory block is not available instead of throwing? That could work too. I really just want the GC to not assume that an allocation error is fatal. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8090] ICE: Assertion failure: 'typen-deco' on line 1703 in file 'cast.c'
http://d.puremagic.com/issues/show_bug.cgi?id=8090 --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-05-24 10:20:37 PDT --- (In reply to comment #1) What version do you use? 2.059 I think this is a dup of bug 8009 (It was a bug in 2.059, and is already fixed), because this ICE doesn't occur in git head. Ok. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8090] ICE: Assertion failure: 'typen-deco' on line 1703 in file 'cast.c'
http://d.puremagic.com/issues/show_bug.cgi?id=8090 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-05-24 10:43:07 PDT --- (In reply to comment #2) (In reply to comment #1) What version do you use? 2.059 Thanks for your answer. Then this is true dup of bug 8009. *** This issue has been marked as a duplicate of issue 8009 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8009] ICE with bad type inside templated function with delegate
http://d.puremagic.com/issues/show_bug.cgi?id=8009 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #4 from Kenji Hara k.hara...@gmail.com 2012-05-24 10:43:08 PDT --- *** Issue 8090 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: ---
[Issue 8112] std.algorithm.fill must accept InputRange
http://d.puremagic.com/issues/show_bug.cgi?id=8112 --- Comment #1 from Guillaume Chatelet chatelet.guilla...@gmail.com 2012-05-24 11:57:55 PDT --- A pull request is pending for this issue https://github.com/D-Programming-Language/phobos/pull/588 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 --- Comment #11 from d...@dawgfoto.de 2012-05-24 12:55:08 PDT --- That could work too. I really just want the GC to not assume that an allocation error is fatal. You could simply override the behavior by providing your own 'extern(C) void onOutOfMemory()'. The linker will pick the one from druntime with the lowest precedence. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8141] New: Two small improvements for std.string maketrans and translate
http://d.puremagic.com/issues/show_bug.cgi?id=8141 Summary: Two small improvements for std.string maketrans and translate Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2012-05-24 14:30:14 PDT --- A small documentation bug report and a little related enhancement request. This is part of the std.string Phobos module: / * $(RED Scheduled for deprecation in March 2012.) * * Construct translation table for translate(). * BUGS: only works with ASCII */ string maketrans(in char[] from, in char[] to) ... } /** * $(RED Scheduled for deprecation in March 2012. * Please use the version of $(D translate) which takes an AA instead.) * * Translate characters in s[] using table created by maketrans(). * Delete chars in delchars[]. * BUGS: only works with ASCII */ string translate()(in char[] s, in char[] transtab, in char[] delchars) My suggestions are: 1) To remove from both ddocs the $(RED Scheduled for deprecation in March 2012.) and replace BUGS: only works with ASCII with something like: NOTE: only works with ASCII. 2) This is the signature of the ascii version of translate: string translate()(in char[] s, in char[] transtab, in char[] delchars) I suggest to add a null default argument for the delchars argument: string translate()(in char[] s, in char[] transtab, in char[] delchars=null) This makes translate() more handy, and it's more similar to the Python str.translate() method this D function is *copied* from: from string import maketrans t = maketrans(abc, XYZ) absent.translate(t, tn) 'XYse' absent.translate(t) 'XYsent' -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8142] New: std.functional.curry isn't flexible enough
http://d.puremagic.com/issues/show_bug.cgi?id=8142
Summary: std.functional.curry isn't flexible enough
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-05-24 14:40:11 PDT ---
std.functional.curry doesn't work if the first argument (the curried one) is a
function. This is a common enough use case:
import std.functional;
auto foo(T)(T function(T x) f, T x) {
return f(x);
}
int bar(int x) { return x * 2; }
alias curry!(foo, bar) fooBar;
void main() {}
DMD 2.060alpha gives:
temp.d(6): Error: expression bar is not a valid template value argument
temp.d(6): Error: template instance std.functional.curry!(foo, bar) error
instantiating
I think D functional-style programming needs a more flexible/uniform currying.
Workaround:
import std.traits: ParameterTypeTuple;
auto foo(alias F)(ParameterTypeTuple!F[0] x) {
return F(x);
}
int bar(int x) { return x * 2; }
alias foo!bar fooBar;
void main() {
assert(fooBar(5) == 10);
}
But this is not as flexible. A language that supports functional programming
needs to handle functions as first class citizens.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8143] New: Safe std.conv.to enum conversion
http://d.puremagic.com/issues/show_bug.cgi?id=8143
Summary: Safe std.conv.to enum conversion
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-05-24 14:46:34 PDT ---
import std.conv: to;
enum Foo : int { A = 10, B = 20 }
void main() {
int x = 10;
Foo f1 = to!Foo(x);
assert(f1 == Foo.A);
x = 5;
Foo f2 = to!Foo(x); // needs to throw an exception
}
DMD 2.060alpha gives:
...\dmd2\src\phobos\std\conv.d(267): Error: template std.conv.toImpl does not
match any function template declaration
...\dmd2\src\phobos\std\conv.d(298): Error: template std.conv.toImpl cannot
deduce template function from argument types !(Foo)(int)
...\dmd2\src\phobos\std\conv.d(267): Error: template instance toImpl!(Foo)
errors instantiating template
temp.d(5): Error: template instance std.conv.to!(Foo).to!(int) error
instantiating
This is handy to *safely* convert run-time values to enum items. Using a
cast(Foo) is useful in other cases, because cast(Foo) doesn't raise a run-time
exceptions. The same difference is visible in this program:
import std.conv: to;
void main() {
int x = -10;
uint y1 = cast(uint)x; // no errors here
uint y2 = to!uint(x); // throws std.conv.ConvOverflowException
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8145] New: void template instantiation?
http://d.puremagic.com/issues/show_bug.cgi?id=8145
Summary: void template instantiation?
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: websites
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-05-24 14:57:18 PDT ---
This compiles with no errors nor warnings (dmd 2.060alpha):
struct Foo(T) {}
Foo!void f;
void main() {}
While a C++ compiler as G++ 4.7 gives:
error: ‘void’ is not a valid type for a template constant parameter
On IRC someone has said this is a feature of D. If this feature is present in D
docs then I suggest to make such note a bit more evident and to explain a bit
how this feature is useful. I think this is useful for C++ programmers.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8146] New: Potentially ambiguous overloaded call
http://d.puremagic.com/issues/show_bug.cgi?id=8146
Summary: Potentially ambiguous overloaded call
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-05-24 15:02:39 PDT ---
This is just a potential enhancement request. It's not an enhancement request
because I am not sure about it.
A thread started by Andrej Mitrovic on D.learn:
http://forum.dlang.org/thread/mailman.1043.1337863952.24740.digitalmars-d-le...@puremagic.com
In dmd 2.060alpha this code compiles and doesn't assert at run-time, so it
calls the second overload:
struct Foo {}
void test(void* test) { assert(0); }
void test(Foo* test) {}
void main() {
test(null);
}
As Andrej comments, shouldn't this be considered an ambiguous call, and refused
at compile time?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5650] A RedBlackTree performance problem
http://d.puremagic.com/issues/show_bug.cgi?id=5650 --- Comment #21 from bearophile_h...@eml.cc 2012-05-24 15:54:51 PDT --- I have asked to people on IRC #D to time the D and C++ versions. Two persons have seen a 4.8 X and 4.6 X speed differences (optimized builds, with G++ using -Ofast -s -flto, MSVC 2010, using standard release build options /OPT:REF /OPT:ICF, and D code compiled with DMD -O -release -inline). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8145] void template instantiation?
http://d.puremagic.com/issues/show_bug.cgi?id=8145 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-05-24 16:41:02 PDT --- I would think a note would be necessary to explain why void would be disallowed. But I can't think of a reason for that. C++ disallowing it is not a sufficient reason. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8145] void template instantiation?
http://d.puremagic.com/issues/show_bug.cgi?id=8145 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2012-05-24 16:42:25 PDT --- I am going to mark this as invalid. If a sufficient rationale is presented, it can be reopened. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 --- Comment #12 from Alex R�nne Petersen a...@lycus.org 2012-05-25 04:35:42 CEST --- (In reply to comment #11) That could work too. I really just want the GC to not assume that an allocation error is fatal. You could simply override the behavior by providing your own 'extern(C) void onOutOfMemory()'. The linker will pick the one from druntime with the lowest precedence. I don't always want out of memory to be handled. In most cases, I do treat it as fatal, but in the few cases I don't, I just want to get a null value back from allocations in the core.memory module. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8098] Inner class method can modify outer's members regardless of constancy
http://d.puremagic.com/issues/show_bug.cgi?id=8098 --- Comment #3 from github-bugzi...@puremagic.com 2012-05-24 21:13:49 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/de20f7f9e50c468fe7758604058d0af6bc7f36aa fix Issue 8098 - Inner class method can modify outer's members regardless of constancy https://github.com/D-Programming-Language/dmd/commit/db915a16aba1db00a5ea59f96ad0b0deea7152b5 Merge pull request #964 from 9rnsr/fix8098 Issue 8098 - Inner class method can modify outer's members regardless of constancy -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8098] Inner class method can modify outer's members regardless of constancy
http://d.puremagic.com/issues/show_bug.cgi?id=8098 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8146] Potentially ambiguous overloaded call
http://d.puremagic.com/issues/show_bug.cgi?id=8146
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-05-24 22:42:16 PDT ---
(In reply to comment #0)
This is just a potential enhancement request. It's not an enhancement request
because I am not sure about it.
A thread started by Andrej Mitrovic on D.learn:
http://forum.dlang.org/thread/mailman.1043.1337863952.24740.digitalmars-d-le...@puremagic.com
In dmd 2.060alpha this code compiles and doesn't assert at run-time, so it
calls the second overload:
struct Foo {}
void test(void* test) { assert(0); }
void test(Foo* test) {}
void main() {
test(null);
}
As Andrej comments, shouldn't this be considered an ambiguous call, and
refused
at compile time?
I think, no.
First, test(Foo*) is specialized than test(void*), because Foo* is convertible
to void*, but opposite isn't.
Next, a null literal has the typeof(null) and it is *most specialized type* of
all reference types. Then typeof(null) is a specialized type than Foo*.
So, with the call 'test(null)', overload resolution will select more
specialized test(Foo*) than test(void*).
Following is a similar case by the class hierarchy.
class B{} // like void*
class C : B{} // like Foo*
class D : C{} // like typeof(null)
void foo(B o){}
void foo(C o){}
void main() {
foo(new D); // calls foo(C)
}
As far as I know, this rule is same as C++.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
