[Issue 6211] __traits (compile) return wrong result when the bug happen
http://d.puremagic.com/issues/show_bug.cgi?id=6211
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC||k.hara...@gmail.com
Resolution||INVALID
--- Comment #6 from Kenji Hara k.hara...@gmail.com 2011-07-11 01:24:01 PDT ---
This is not bug.
In lib.d, you can't access Foo by name (without importing main).
lib.d
void Compiled(T, string memberName)()
{
T t; // ok
Foo foo; // error!
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6286] New: Static arrays can not be assigned from const(T)[N] to T[N]
http://d.puremagic.com/issues/show_bug.cgi?id=6286
Summary: Static arrays can not be assigned from const(T)[N] to
T[N]
Product: D
Version: unspecified
Platform: Other
OS/Version: Windows
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: lud...@informatik.uni-luebeck.de
--- Comment #0 from S�nke Ludwig lud...@informatik.uni-luebeck.de 2011-07-11
01:52:55 PDT ---
The following snipped worked up to DMD 2.053 but fails on 2.054:
---
void test()
{
const(int)[4] src = [1, 2, 3, 4];
int[4] dst;
dst = src; // Error: cannot implicitly convert expression (src) of type
const(int[4u]) to int[]
dst[] = src[]; // still works
}
---
The assignment T[N] = const(T)[N] should work as long as T = const(T) works
as there is no aliasing goind on but just a plain copy.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6286] Static arrays can not be assigned from const(T)[N] to T[N]
http://d.puremagic.com/issues/show_bug.cgi?id=6286 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2011-07-11 02:05:28 PDT --- I don't think that this is a bug but rather than dmd used to be buggy with regards to this case. dst = src; is assigning src to dst. And assigning a dynamic array to a static one isn't legal. If dst = src; were allowed, then it would be inconsistent with the case where both dst and src are dynamic arrays. dst[] = src[]; on the other hand is specifically copying the elements of src to the elements of dst. So, it's possible that this is a regression and that dst = src; is supposed to just translate to dst[] = src[]; when dst is a static array, but I think that it's far more likely that this is a case where a long-standing bug was fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6286] Static arrays can not be assigned from const(T)[N] to T[N]
http://d.puremagic.com/issues/show_bug.cgi?id=6286 --- Comment #2 from S�nke Ludwig lud...@informatik.uni-luebeck.de 2011-07-11 04:09:49 PDT --- Note that in the test case both, the source and the destination are static arrays of the same size. There is no reason why a direct assignment should not work here. I think the compiler mistakes the left side here as a dynamic array. In the case of really assigning a dynamic array to a static one, the decision is definitely not so obvious as it could lead to a hidden runtime error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 --- Comment #3 from Stewart Gordon s...@iname.com 2011-07-11 04:21:01 PDT --- I disagree. The primary purpose of casting is simply to force an expression to a specified type. This cast may or may not be legal. For example, you can't cast between different class and struct types arbitrarily, or cast an array reference directly to a long (although, on 32-bit systems, they are the same size). It's true that some casts are unsafe, such as casting away constancy. But this is something one might actually want to do for various reasons (such as interfacing some foreign APIs), and the behaviour is documented (though it would be better if the means were explicit). On the other hand, I can't see anybody wanting what actually happens when you try casting an object array to an interface array. And it's an easy mistake to make, either - by someone who hasn't yet learned that they aren't compatible - by forgetting whether something's a class or an interface - when trying in vain to do generic programming stuff that will work with either classes or interfaces Moreover, unless I'm mistaken there's no indication in the spec that it's legal but dangerous. As such, it should either be illegal, or convert at runtime. The drawback of the latter is that it would have to reallocate in order to perform the conversion, which would cause further confusion in that carray and iarray point to different areas of memory, contrary to the usual behaviour of array casting. But I suppose what could be done is to define iarray[] = carray; to convert each element of carray on copy, so that it works. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 --- Comment #4 from Stewart Gordon s...@iname.com 2011-07-11 04:28:28 PDT --- On the other hand, I can't see anybody wanting what actually happens when you try casting an object array to an interface array. And it's an easy mistake to make, either - by someone who hasn't yet learned that they aren't compatible - by forgetting whether something's a class or an interface - when trying in vain to do generic programming stuff that will work with either classes or interfaces Add to that: when a library template that was only designed to work with classes contains such code, and somebody tries to use it with an interface. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6192] std.algorithm.sort performance
http://d.puremagic.com/issues/show_bug.cgi?id=6192 --- Comment #4 from bearophile_h...@eml.cc 2011-07-11 04:58:06 PDT --- Thank you for your work. The new timings (after pull 74): sort-sort2 benchmarks (milliseconds), N=600: Random distribution: sort:1261 sort2: 1201 Already sorted arrays: sort: 300 sort2:441 Inverted order arrays: sort: 315 sort2:729 Few random doubles appended to the sorted arrays: sort:9962 sort2:632 The last case is a common use case in Python code. Python programmers sometimes append unsorted items to a sorted list, and once in a while they sort it. Because the Timsort used in Python (and Java) is able to face this case very well, this is an efficient strategy to keep a rarely updated list sorted in Python. I don't know how much common this pattern is in real D code (but experience shows that often real-world data is already partially sorted). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 --- Comment #5 from yebblies yebbl...@gmail.com 2011-07-11 23:36:00 EST --- I do understand, but nothing you've said changes the fact that the behavior is completely intentional. Cast is, as always, a blunt instrument that bypasses the type system. Another example would be casting int to float vs casting int[] to float[]. The compiler's behavior here is as intended and consistent. Since 2008, when this bug was reported, some things have improved. This cast is not allowed in @safe code and std.conv.to is quite capable of performing the element by element conversion. I don't see introducing an implicit allocation and a loop as the solution when the safe way is already supported. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 --- Comment #6 from Stewart Gordon s...@iname.com 2011-07-11 06:45:20 PDT --- (In reply to comment #5) I do understand, but nothing you've said changes the fact that the behavior is completely intentional. What is your source for this fact? Cast is, as always, a blunt instrument that bypasses the type system. No it isn't. That's what I've just been explaining. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 --- Comment #7 from yebblies yebbl...@gmail.com 2011-07-12 00:38:32 EST --- (In reply to comment #6) (In reply to comment #5) I do understand, but nothing you've said changes the fact that the behavior is completely intentional. What is your source for this fact? Conversations on the newsgroup, where array casting has been discussed. If I could find a post I'd link it, but I really have no intention of spending any more of my time searching. I guess we can wait until the spec is updated to actually reflect what dmd does. Cast is, as always, a blunt instrument that bypasses the type system. No it isn't. That's what I've just been explaining. I guess we'll just have to agree to disagree then. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6286] Regression(2.054): Static arrays can not be assigned from const(T)[N] to T[N]
http://d.puremagic.com/issues/show_bug.cgi?id=6286 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch, rejects-valid CC||yebbl...@gmail.com Summary|Static arrays can not be|Regression(2.054): Static |assigned from const(T)[N] |arrays can not be assigned |to T[N] |from const(T)[N] to T[N] --- Comment #3 from yebblies yebbl...@gmail.com 2011-07-12 00:50:34 EST --- I fear this one was my fault! https://github.com/D-Programming-Language/dmd/pull/232 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Keywords|wrong-code | CC||schvei...@yahoo.com Severity|normal |enhancement --- Comment #8 from Steven Schveighoffer schvei...@yahoo.com 2011-07-11 08:05:14 PDT --- Casting is for all intents and purposes a blunt instrument. The fact that cast can call runtime functions or member functions in certain situations somewhat muddies the waters. IMO, cast should be reserved for specifically I know what I'm doing stuff. dynamic cast (casting from a base to derived class) should really be handled by a library function, as it is so dangerous to use cast in this case (you can unintentionally remove const or immutable). Same thing for opCast. For me, the litmus test for this is: float f = 1.5; int i = cast(int)f; // now contains 1 float[] farr = [1.5, 2.5]; int[] iarr = cast(int[])farr; is it reasonable for someone to expect iarr to contain the binary float representation of [1.5, 2.5], or should it contain [1, 2]? I think both cases are reasonable, and the former is much more difficult to do a different way, whereas a library function already exists to do the latter (std.conv.to). It would be extremely inconsistent for arrays to cast differently depending on the element type. Remember that arrays are akin to pointers, and should cast similarly (casting a pointer does nothing except reinterpret the type). The final thing is, cast should *not* be doing hidden allocations. I think this bug is really an enhancement request, because the current code works as designed. Marking as such. (In reply to comment #6) (In reply to comment #5) I do understand, but nothing you've said changes the fact that the behavior is completely intentional. What is your source for this fact? http://www.digitalmars.com/d/2.0/expression.html#CastExpression Note the lack of special case (and there are several) for casting arrays. In fact, mention of array casting should be made there, to indicate how the length member is affected. I'd throw in pointer casting as well. So I'd interpret that as the D spec and the compiler was intentionally *not* designed to special case casting of arrays of classes to arrays of interfaces and vice versa. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6026] DLL example needs update due to missing core.dll_helper
http://d.puremagic.com/issues/show_bug.cgi?id=6026 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 08:18:49 PDT --- Fixed in 2.054 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6021] std.net.isemail missing from dpl.org
http://d.puremagic.com/issues/show_bug.cgi?id=6021 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Summary|std.parallelism missing |std.net.isemail missing |from dpl.org|from dpl.org --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 08:19:45 PDT --- Ok parallelism is in but isemail is still not up so I'll rename the bug to cover that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5869] std.thread needs to be removed
http://d.puremagic.com/issues/show_bug.cgi?id=5869 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 08:21:36 PDT --- Fixed in 2.054 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5836] std.typetuple.staticIndexOf's example code missing %s in call to writefln
http://d.puremagic.com/issues/show_bug.cgi?id=5836 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 08:22:13 PDT --- Fixed in 2.054 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5598] rdmd does not fail on invalid filename
http://d.puremagic.com/issues/show_bug.cgi?id=5598 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 08:24:04 PDT --- I'm setting this as resolved since RDMD now echoes when it fails to compile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5458] scope for function parameters is not documented
http://d.puremagic.com/issues/show_bug.cgi?id=5458 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 08:24:46 PDT --- Fixed in 2.054 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 08:27:55 PDT --- Fixed in 2.054 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6101] Documentation for dead modules still distributed with DMD
http://d.puremagic.com/issues/show_bug.cgi?id=6101 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 08:29:03 PDT --- std_gc and std_thread now redirect to their core equivalents, others were removed. Fixed in 2.054. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6286] Regression(2.054): Static arrays can not be assigned from const(T)[N] to T[N]
http://d.puremagic.com/issues/show_bug.cgi?id=6286 --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2011-07-11 08:48:22 PDT --- Ah yes. I didn't read carefully enough. If both src and dst are static arrays, then dst = src; should work. It's when one is a dynamic array that it shouldn't. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #9 from Jonathan M Davis jmdavisp...@gmx.com 2011-07-11 08:58:04 PDT --- On a semi-related but not all that related note, I would point out to Steven that Kenji has made pull requests related to std.conv.to, one of which will make std.conv.to use opCast for user-defined conversions if a user-defined type has an opCast, so if you don't think that opCast should be used for such situations (that is, if you equate that to dangerous as you've been discussing here), then you should comment on the pull request: https://github.com/D-Programming-Language/phobos/pull/118 https://github.com/D-Programming-Language/phobos/pull/119 https://github.com/D-Programming-Language/phobos/pull/122 If no one else comments on those changes soon, they're likely to go in soon. But they're giving a way to avoid having to use casts in your own code, so I would think that they'd be an improvement, because then casts are used _less_ rather than more. In any case, as for this particular bug, casts are definitely a blunt instrument, so they tend to be legal whether you really want them to or not. They're not quite as blunt as they are in C (e.g. they _do_ do checks when converting between classes), but they're still pretty blunt. It's one of the reasons that it's typically better to use std.conv.to rather than casting. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 --- Comment #10 from Steven Schveighoffer schvei...@yahoo.com 2011-07-11 09:08:48 PDT --- (In reply to comment #9) On a semi-related but not all that related note Interesting :) I would point out to Steven that Kenji has made pull requests related to std.conv.to, one of which will make std.conv.to use opCast for user-defined conversions if a user-defined type has an opCast, so if you don't think that opCast should be used for such situations (that is, if you equate that to dangerous as you've been discussing here), then you should comment on the pull request: calling opCast!(T) directly is not nearly as dangerous as using cast(T). It is expected that opCast does not do unsafe things. Plus it is a regular function, so it must obey the type system (unless of course it uses casts underneath). In particular, it does *not* affect const/immutable unless opCast is specifically written to do so. So I have no problem with opCast being called from std.conv.to. Actually, I'm looking at std.conv.to in that pull request and see a significant bug, because cast is so dangerous! (will file in a minute) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6287] New: function pointers to non-static function without an object-instance
http://d.puremagic.com/issues/show_bug.cgi?id=6287
Summary: function pointers to non-static function without an
object-instance
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: suicide...@xited.de
--- Comment #0 from suicide...@xited.de 2011-07-11 09:32:15 PDT ---
import std.stdio;
struct test
{
int foo(int k) //forgot to defined as static
{
return k;
}
}
int main(string[] argv)
{
int function(int) fp;
fp = test.foo; //this should not be possible, as foo is not static. it
allows dirty hacks, though.
int x = fp(99);
writeln(x);
return 0;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6287] function pointers to non-static function without an object-instance
http://d.puremagic.com/issues/show_bug.cgi?id=6287 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com 2011-07-12 02:44:12 EST --- *** This issue has been marked as a duplicate of issue 3720 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3720] Taking address of member functions possible without an instance
http://d.puremagic.com/issues/show_bug.cgi?id=3720 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||suicide...@xited.de --- Comment #3 from yebblies yebbl...@gmail.com 2011-07-12 02:44:12 EST --- *** Issue 6287 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 6277] Disallow short floating point literals
http://d.puremagic.com/issues/show_bug.cgi?id=6277
--- Comment #4 from bearophile_h...@eml.cc 2011-07-11 09:55:45 PDT ---
Steven Schveighoffer reminds this is probably OK (this compiles with DMD
2.054):
void main() {
auto x = 1f;
static assert(is(typeof(x) == float));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4407] Catch wrong argument-attribute assignments in methods
http://d.puremagic.com/issues/show_bug.cgi?id=4407
--- Comment #4 from bearophile_h...@eml.cc 2011-07-11 10:03:16 PDT ---
One example of bug related to x=x; found inside the good QT libs:
PassRefPtrStructure
Structure::getterSetterTransition(Structure* structure)
{
...
RefPtrStructure transition = create(
structure-storedPrototype(), structure-typeInfo());
transition-m_propertyStorageCapacity =
structure-m_propertyStorageCapacity;
transition-m_hasGetterSetterProperties =
transition-m_hasGetterSetterProperties;
transition-m_hasNonEnumerableProperties =
structure-m_hasNonEnumerableProperties;
transition-m_specificFunctionThrashCount =
structure-m_specificFunctionThrashCount;
...
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6288] New: std.conv.to removes const/immutable when converting a class
http://d.puremagic.com/issues/show_bug.cgi?id=6288
Summary: std.conv.to removes const/immutable when converting a
class
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: schvei...@yahoo.com
--- Comment #0 from Steven Schveighoffer schvei...@yahoo.com 2011-07-11
10:19:14 PDT ---
The code in std.conv.to looks like this for converting to base/derived class:
/**
Object-to-object conversions throw exception when the source is
non-null and the target is null.
*/
T toImpl(T, S)(S value) if (is(S : Object) is(T : Object))
{
auto result = cast(T) value;
if (!result value)
{
throw new ConvException(Cannot convert object of static type
~S.classinfo.name~ and dynamic type ~value.classinfo.name
~ to type ~T.classinfo.name);
}
return result;
}
This does not take into account that cast can easily remove const or immutable
decorations.
For example:
import std.conv;
class C {}
class D : C {}
void main()
{
const(C) c = new D;
D d = to!D(c);
assert(d !is null);
}
This compiles as of 2.054, and clearly is removing const without requiring a
cast.
Unfortunately, cast() is the mechanism to do dynamic conversions, so the logic
to allow compilation needs to check that const is not being removed or
immutable is not being removed/added.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 --- Comment #11 from Steven Schveighoffer schvei...@yahoo.com 2011-07-11 10:20:10 PDT --- (In reply to comment #10) Actually, I'm looking at std.conv.to in that pull request and see a significant bug, because cast is so dangerous! (will file in a minute) Note issue 6288 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6284] [Regression 2.054] 'pure' does not work with 'with' statement
http://d.puremagic.com/issues/show_bug.cgi?id=6284 kenn...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #2 from kenn...@gmail.com 2011-07-11 13:33:35 PDT --- DMD pull #233. https://github.com/D-Programming-Language/dmd/pull/233 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 --- Comment #12 from Stewart Gordon s...@iname.com 2011-07-11 14:41:54 PDT --- (In reply to comment #8) IMO, cast should be reserved for specifically I know what I'm doing stuff. dynamic cast (casting from a base to derived class) should really be handled by a library function, as it is so dangerous to use cast in this case (you can unintentionally remove const or immutable). Same thing for opCast. Indeed, it's a shame D has only one cast operator, which applies to both safe and unsafe conversions. Contrast C++, which has five (does dynamic_cast count as safe?) float[] farr = [1.5, 2.5]; int[] iarr = cast(int[])farr; is it reasonable for someone to expect iarr to contain the binary float representation of [1.5, 2.5], or should it contain [1, 2]? I think both cases are reasonable, and the former is much more difficult to do a different way, int[] iarr = cast(int[]) cast(void[]) farr; doesn't seem much more difficult to me. Casting to void[] makes it explicit that you want to discard the existing semantics of the byte sequence. http://www.digitalmars.com/d/2.0/expression.html#CastExpression Note the lack of special case (and there are several) for casting arrays. In fact, mention of array casting should be made there, to indicate how the length member is affected. I'd throw in pointer casting as well. Indeed, ISTM probably just an oversight that (DM)D silently accepts this cast that never does anything useful. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2270] cast produces invalid arrays at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=2270 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #13 from bearophile_h...@eml.cc 2011-07-11 16:03:56 PDT --- (In reply to comment #12) Indeed, it's a shame D has only one cast operator, which applies to both safe and unsafe conversions. Contrast C++, which has five (does dynamic_cast count as safe?) Some casts are easy enough to implement in Phobos library code, as example see bug 5559 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6289] New: Make slices of const/immutable arrays mutable (but keep the elements const/immutable)
http://d.puremagic.com/issues/show_bug.cgi?id=6289
Summary: Make slices of const/immutable arrays mutable (but
keep the elements const/immutable)
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2011-07-11 17:12:35
PDT ---
Okay. If you have
immutable val = [1, 2, 3, 4];
void func(immutable(int)[] arg) {}
you can pass val to func even though val is fully immutable. The compiler
realizes that it's safe, because func cannot alter the original array. The
array in the function is a slice of the original and can't affect the original
(since the elements are immutable). However, even though this is true, the type
of a slice of an immutable int[], is still immutable int[], not
immutable(int)[] as with the function parameter. I'd like to see
immutable val = [1, 2, 3, 4];
assert(is(typeof(val) == immutable(int[])));
assert(is(typeof(val[]) == immutable(int)[]));
The slice is then mutable (though its elements are not) - which makes sense,
since that's exactly what the function described above does. The reason that I
want this to be the case is that you can then use immutable arrays with
range-based functions if you slice them (just as is the case with static
arrays). As it stands, both
find(val, 3);
and
find(val[], 3);
are illegal, because the compiler tries to instantiate find with
immutable(int[]). But if the type of a slice of val were immutable(int)[], then
the second find call would work. This would help solve the problem of immutable
arrays not working with range-based functions (see bug# 6148). Then, if you
slice static arrays and immutable/const arrays (just as you'd have to do with
container), they will work with range-based functions. As it stands, that works
with static arrays but not immutable or const arrays.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4890] GC.collect() deadlocks multithreaded program.
http://d.puremagic.com/issues/show_bug.cgi?id=4890 Jakob Bornecrantz wallbra...@gmail.com changed: What|Removed |Added CC||wallbra...@gmail.com --- Comment #5 from Jakob Bornecrantz wallbra...@gmail.com 2011-07-11 18:01:31 PDT --- This looks fixed with 2.054 on MacOSX, at least I can repro this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6290] New: GC breaks if a thread is allocated on Mac OSX
http://d.puremagic.com/issues/show_bug.cgi?id=6290
Summary: GC breaks if a thread is allocated on Mac OSX
Product: D
Version: D1
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: blocker
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: wallbra...@gmail.com
--- Comment #0 from Jakob Bornecrantz wallbra...@gmail.com 2011-07-11
19:07:06 PDT ---
class MyThread : public Thread {
int run() {
new byte[1024*1024];
return 0;
}
}
int main(char[][] args) {
auto t = new MyThread();
t.start();
t.wait();
return 0;
}
The above program is totally broken on Mac due to a bug in the GC. Patch
available in pull request here:
https://github.com/D-Programming-Language/phobos/pull/141 after pulling that
request, please add this example as a unittest or something, this embarrassment
have been in there since at least 1.064.
Cheers Jakob.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6290] GC breaks if a thread is allocated on Mac OSX
http://d.puremagic.com/issues/show_bug.cgi?id=6290 Jakob Bornecrantz wallbra...@gmail.com changed: What|Removed |Added Priority|P2 |P1 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6291] New: Warn on likely hex literal bug
http://d.puremagic.com/issues/show_bug.cgi?id=6291 Summary: Warn on likely hex literal bug Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 21:14:05 PDT --- I think this could be a useful test case for a lint-like tool, and perhaps not DMD itself. But I'm putting it in bugzilla just so I don't ever forget that I ran into it: enum paFloat32 = 0x_0001; enum paInt32 = 0x_0002; enum paInt24 = 0x_0004; enum paInt16 = 0x_0008; enum paInt8 = 0x_00100; enum paUInt8 = 0x_0020; enum paCustomFormat = 0x0001_; enum paNonInterleaved = 0x8000_; Hmm.. all seems fine. Except line 5, there's an extra zero at the end! The integer value of paInt8 is 256 instead of 16. I've had this bug manifest itself while translating a C header file. I don't really know how it got there, I know I've added the underscores after HTOD made a pass over the C header, and that's where I screwed up and must have added another zero. There's probably not much to do about this. It's still a valid hex literal, it doesn't overflow, and the underscores are purely conventional and not something the compiler forces you to do every 4 spaces. But it caused a bug and it's worth mentioning. Sorry if this doesn't belong here.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6291] Warn on likely hex literal bug
http://d.puremagic.com/issues/show_bug.cgi?id=6291 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 21:25:13 PDT --- *correction* I just saw my git commit, the code was: enum PaSampleFormat paFloat32 = 0x0001; -enum PaSampleFormat paInt32 = 0x0002; -enum PaSampleFormat paInt24 = 0x0004; -enum PaSampleFormat paInt16 = 0x0008; -enum PaSampleFormat paInt8 = 0x00010; -enum PaSampleFormat paUInt8 = 0x0020; -enum PaSampleFormat paCustomFormat = 0x0001; -enum PaSampleFormat paNonInterleaved = 0x8000; So I actually spotted the bug *after* I added the underscores. Heh, I guess this isn't an enhancement request but just a heads up for using underscores, it's a great feature. I'm closing this down. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6292] New: HTOD hides constants behind a comment
http://d.puremagic.com/issues/show_bug.cgi?id=6292 Summary: HTOD hides constants behind a comment Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: major Priority: P2 Component: htod AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-11 21:56:47 PDT --- #define FOO 128 #define BAR 256 /* blablabla blablabla */ htod -hc test.h /* Converted to D from test.h by htod */ module test; /* blablabla const FOO = 128; blablabla */ Woops. FOO is hidden behind a /* */ comment, and BAR is gone! Ha-ha... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
