[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910 --- Comment #8 from Daniel Cousens daniel...@bigpond.com 2012-10-29 23:36:15 PDT --- Frankly thats a terrible alternative. Perhaps static array specialisations are in order then; assuming current implementations can't be modified to suit. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910 --- Comment #9 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-29 23:41:54 PDT --- Frankly thats a terrible alternative. Perhaps static array specialisations are in order then; assuming current implementations can't be modified to suit. So, you think that copying a static array is a good idea? Because that's what on overload for a static array would do. And all that overload could do would be to slice the static array and pass it to the normal overload (because static arrays are _not_ ranges and _cannot_ be, because you can't pop any of their elements off), which would lead to the slice being completely invalid once the function returned, meaning that the result would be completely unsafe and invalid. So no, that wouldn't work. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8909] is{File, Dir, SymLink} mix return error code and exception
http://d.puremagic.com/issues/show_bug.cgi?id=8909 --- Comment #9 from Dimitri Sabadie dimitri.saba...@gmail.com 2012-10-30 01:24:12 PDT --- Ok, got you meant. The thing is I’d more likely use a two-steps approach (if exists then if isFile, for instance). Some guys talk about concurrency, I think it’s not a good argument here because isFile is not atomic either if used with exception. Though I understand why it’s marked as WONTFIX. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8893] [ICE][CTFE] (interpret.c, line 3598) with failed array access
http://d.puremagic.com/issues/show_bug.cgi?id=8893 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from yebblies yebbl...@gmail.com 2012-10-30 19:29:20 EST --- I can't reproduce this on D1. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8893] [ICE][CTFE] (interpret.c, line 3598) with failed array access
http://d.puremagic.com/issues/show_bug.cgi?id=8893 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||CTFE, ice, pull CC||yebbl...@gmail.com Platform|x86 |All AssignedTo|nob...@puremagic.com|clugd...@yahoo.com.au OS/Version|Windows |All Severity|normal |major --- Comment #1 from yebblies yebbl...@gmail.com 2012-10-30 19:26:03 EST --- https://github.com/D-Programming-Language/dmd/pull/1236 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8893] [ICE][CTFE] (interpret.c, line 3598) with failed array access
http://d.puremagic.com/issues/show_bug.cgi?id=8893 --- Comment #2 from github-bugzi...@puremagic.com 2012-10-30 01:26:29 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f8015992623223985419fa1b69b5102feb6d462c Fix issue 8893 ICE(interpret.c) with invalid struct literal The implicit conversion can fail. In this case the struct literal is invalid (which means it will never reach CTFE). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8909] is{File, Dir, SymLink} mix return error code and exception
http://d.puremagic.com/issues/show_bug.cgi?id=8909 --- Comment #10 from Dimitri Sabadie dimitri.saba...@gmail.com 2012-10-30 01:31:37 PDT --- A good link about the topic: http://www.digitalmars.com/d/archives/digitalmars/D/674.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8905] DList.Range: Internal error, inconsistent state
http://d.puremagic.com/issues/show_bug.cgi?id=8905
--- Comment #3 from monarchdo...@gmail.com 2012-10-30 01:44:41 PDT ---
(In reply to comment #2)
(In reply to comment #1)
I don't think there is *ANY* way to ever make this work, and I'd suggest
either
of:
*Re-writing the documentation.
*Removing the function if the documentation is correct.
I don't think so, either, and I agree with the recommendation.
Wait, thinking about it, technically, it could actually work, if the original
range then produced :[1, 2, 3, 4, 7].
The thing is that such semantics are un-natural. It would correspond to my
notion of a Dlist is just a view into a chain of nodes. The problem is that I
*still* don't know if that would be the intended behavior...
BTW, here is a fun bug related to said view of chain behavior:
//
import std.container;
import std.stdio;
void main()
{
auto list = make!(DList!int)(1,2,3,4,5);
auto r = list[];
list.stableRemoveBack();
list.stableRemoveFront();
list.stableRemove(list[]);
writeln(My empty list: , list[]);
writeln(My original slice: , r);
}
//
My empty list: [2, 3, 4]
My original slice: [1, 5]
//
Fixing this is doable, but it makes the implementation *very* complicated
(standard dlist assumptions don't hold anymore). Not to mention it allows for
some *very* weird semantics. Not worth it, IMO.
I'd have suggested that DList be changed to have a simpler reference semantic
(all Dlist share a common payload), with explicit destruction of removed nodes
(and invalidation of ranges that index them). EG: The DList we all know and
love...
But seeing how much feedback I've received, I'm not sure I feel like pushing
for this one :(
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8905] DList.Range: Internal error, inconsistent state
http://d.puremagic.com/issues/show_bug.cgi?id=8905 --- Comment #4 from monarchdo...@gmail.com 2012-10-30 03:28:21 PDT --- (In reply to comment #3) [SNIP] Actually, I remember that I had corrected all these bugs, but had never gotten around to committing them... I'll do it then. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8912] New: Error compiling core.memory - possible DDoc problem
http://d.puremagic.com/issues/show_bug.cgi?id=8912 Summary: Error compiling core.memory - possible DDoc problem Product: D Version: D2 Platform: x86 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: k...@redstar.de --- Comment #0 from k...@redstar.de 2012-10-30 04:45:29 PDT --- I am using head version of DMD. While compiling druntime on Windows (32 bit) I get the following error: dmd -c -w -o- -Isrc -Iimport -Dfdoc\core_memory.html -version=CoreDdoc src\core\ memory.d (16): Error: unterminated character constant (39): Error: unterminated character constant Both lines are in a comment. Maybe something wrong with DDoc generation? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8912] Error compiling core.memory - possible DDoc problem
http://d.puremagic.com/issues/show_bug.cgi?id=8912 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2012-10-30 05:59:42 PDT --- During the compilation of DMD/druntime/Phobos there are other things that pop up: make clean del ..\..\lib\cppunit.lib Can't find C:\dmd2\src\dmd\src\cppunit-1.12.1\lib\cppunit.lib dmc -c -Iroot;\dm\include -o -cpp -DDM_TARGET_CPU_X86=1 dsymbol else if (ce-type (t = ce-type-toBasetype()) ^ dsymbol.c(1351) : Warning 2: possible unintended assignment if ((t = e-type-toBasetype()) t-ty == Tfunction) ^ dsymbol.c(1417) : Warning 2: possible unintended assignment -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8893] [ICE][CTFE] (interpret.c, line 3598) with failed array access
http://d.puremagic.com/issues/show_bug.cgi?id=8893
--- Comment #4 from bearophile_h...@eml.cc 2012-10-30 06:01:42 PDT ---
struct Foo {
char[3] data;
}
int bar(Foo f) {
return f.data[0];
}
void main() {
enum f = Foo(['A', 'B']);
enum int b = bar(f);
}
The error message seems not correct:
test.d(8): Error: cannot implicitly convert expression (['A','B']) of type
char[] to char
Instead of:
test.d(8): Error: cannot implicitly convert expression (['A','B']) of type
char[] to char[3]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 519] Invariant not called from autogenerated class/struct constructor/destructor
http://d.puremagic.com/issues/show_bug.cgi?id=519
Denis Shelomovskij verylonglogin@gmail.com changed:
What|Removed |Added
CC||verylonglogin@gmail.com
Summary|Invariant not called from |Invariant not called from
|autogenerated constructor |autogenerated class/struct
||constructor/destructor
--- Comment #8 from Denis Shelomovskij verylonglogin@gmail.com 2012-10-30
16:05:58 MSK ---
Structs have the same problem:
---
import std.stdio;
struct S
{
invariant() { writeln(invariant); } // never called
// ~this() { writeln(~this); } // uncomment to call invariant
}
void main()
{
auto s = S();
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 780] The assignment of 'this' is allowed
http://d.puremagic.com/issues/show_bug.cgi?id=780 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added CC||verylonglogin@gmail.com Version|D1 D2 |D1 --- Comment #6 from Denis Shelomovskij verylonglogin@gmail.com 2012-10-30 16:29:54 MSK --- (In reply to comment #5) After fixing bug 4596, this will be an issue for only D1. Bug 4596 is fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8913] New: Wrong code in IfStatement condition Expression
http://d.puremagic.com/issues/show_bug.cgi?id=8913
Summary: Wrong code in IfStatement condition Expression
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ibuc...@ubuntu.com
--- Comment #0 from Iain Buclaw ibuc...@ubuntu.com 2012-10-30 06:44:09 PDT ---
struct A {
char[1] b;
}
void main()
{
A c;
if (*c.b.ptr)
return;
return;
}
The following of type char
*c.b.ptr
Generates and sends to the backend as type char[1]
c.b
This is wrong and invalid (non-scalar types cannot be used as boolean types).
Regards
Iain.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3467] Non-int integral template parameters not correctly propagated
http://d.puremagic.com/issues/show_bug.cgi?id=3467 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Version|D1 D2 |D1 Resolution|FIXED | --- Comment #12 from Denis Shelomovskij verylonglogin@gmail.com 2012-10-30 16:49:11 MSK --- (In reply to comment #10) https://github.com/D-Programming-Language/dmd/commit/f8ad107800a2c9bf116779a49abe9945daf9d05f Resolved for D2 only. So it's D1 issue now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6763] Using TypeTuple with (const/in/ref etc.) changes it forever
http://d.puremagic.com/issues/show_bug.cgi?id=6763 --- Comment #3 from Denis Shelomovskij verylonglogin@gmail.com 2012-10-30 16:54:48 MSK --- Is it fixed for D1? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8914] New: Wrong `escaping reference` error on returning static array
http://d.puremagic.com/issues/show_bug.cgi?id=8914
Summary: Wrong `escaping reference` error on returning static
array
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2012-10-30
17:09:52 MSK ---
As static array is a value type, there should be no error:
---
int[2] f(int[2] arr...)
{ return arr; } // Error: escaping reference to variadic parameter arr
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356
Denis Shelomovskij verylonglogin@gmail.com changed:
What|Removed |Added
CC||verylonglogin@gmail.com
--- Comment #13 from Denis Shelomovskij verylonglogin@gmail.com
2012-10-30 17:17:29 MSK ---
Workaround for those who like a, b, c initialization but need more
performance (not: it still calls `_d_arraycopy`):
---
T[n] makeStaticArray(T, size_t n)(T[n] data...)
// { return data; }
{ T[n] res; res = data; return res; } // Issue 8914 workaround
void setStaticArray(T, size_t n)(ref T[n] array, T[n] data...)
{ array = data; }
void main()
{
auto x = makeStaticArray(1, 2, 3);
static assert(is(typeof(x) == int[3]));
assert(x == [1, 2, 3]);
int[3] y;
y.setStaticArray(1, 2, 3);
assert(y == [1, 2, 3]);
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7358] `final switch` over enum should add throwing default in debug mode at least
http://d.puremagic.com/issues/show_bug.cgi?id=7358 --- Comment #4 from github-bugzi...@puremagic.com 2012-10-30 07:42:24 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b9ad0b8517c23fa4deca3ddb433dfbb0fab8fb65 Issue 7358 - final switch over enum should add throwing default in debug mode at least Add a throwing default case when compiled with asserts on. https://github.com/D-Programming-Language/dmd/commit/638d81d792d5f12c887de3da6ab00c07d9f227b2 Merge pull request #673 from yebblies/issue7358 Issue 7358 - final switch over enum should add throwing default in debug mode -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7358] `final switch` over enum should add throwing default in debug mode at least
http://d.puremagic.com/issues/show_bug.cgi?id=7358 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8913] Wrong code in IfStatement condition Expression
http://d.puremagic.com/issues/show_bug.cgi?id=8913 --- Comment #1 from Iain Buclaw ibuc...@ubuntu.com 2012-10-30 08:17:21 PDT --- This conversion occurs in PtrExp::optimize. *c.b - c.b For static array types, would there be a problem doing this instead? *c.b - c.b[0] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8915] New: Current lvalue behavior looks inconsistent for structs and buildin types
http://d.puremagic.com/issues/show_bug.cgi?id=8915
Summary: Current lvalue behavior looks inconsistent for structs
and buildin types
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2012-10-30
18:30:09 MSK ---
---
int iFunc() { return 0; };
enum int iEnum = iFunc();
struct S { }
S sFunc() { return S(); };
enum S sEnum = sFunc();
void refI(ref int) { }
void refS(ref S) { }
void main()
{
refI(int.init); // Error: constant 0 is not an lvalue
refI(iEnum); // Error: constant 0 is not an lvalue
refI(iFunc()); // Error: iFunc() is not an lvalue
refS(S()); // compiles
refS(S.init); // compiles
refS(sFunc()); // Error: f() is not an lvalue
refS(sEnum);// compiles
}
---
This leads to inability to define `NonZeroUInt32` struct e.g. with same
semantics as `uint`.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8916] New: How about to disable ++, --, and assignments to non-lvalues?
http://d.puremagic.com/issues/show_bug.cgi?id=8916
Summary: How about to disable ++, --, and assignments to
non-lvalues?
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2012-10-30
18:47:15 MSK ---
Disabling ++, -- and assignments to non-lvalues (opAssign, opOpAssign,
opIndexAssign, opIndexOpAssign, opSliceAssign, opSliceOpAssign) will allow to
define user types with same semantics as build-in types (arithmetic and static
arrays):
---
struct S
{
void opUnary(string op : ++)() { }
void opAssign(int) { }
}
int iFunc() { return 0; }
int[1] sarrFunc() { return [0]; }
S sFunc() { return S(); }
void main()
{
++int.init; // Error: constant 0 is not an lvalue
++iFunc(); // Error: iFunc() is not an lvalue
++(int[1]).init; // Error: [0] is not an lvalue
++sarrFunc(); // Error: sarrFunc() is not an lvalue
// currently compiles, but shouldn't:
++S.init;
++sFunc();
S.init = 3;
sFunc() = 3;
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8917] New: Array operation a[] + a[] not implemented
http://d.puremagic.com/issues/show_bug.cgi?id=8917
Summary: Array operation a[] + a[] not implemented
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nilsboss...@googlemail.com
--- Comment #0 from Nils nilsboss...@googlemail.com 2012-10-30 09:22:28 PDT
---
---
cat test.d CODE
void main() {
int[3] a;
int[3] b = a[] + a[];
}
CODE
dmd test.d
---
test.d(3): Error: Array operation a[] + a[] not implemented
---
Works with 2.060. Fails since this commit:
https://github.com/D-Programming-Language/dmd/commit/da8e2a038105ad0149a8f66fbcfe31079ce3a534
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8918] New: Wrong sized literal assigned to fixed size literal error message
http://d.puremagic.com/issues/show_bug.cgi?id=8918
Summary: Wrong sized literal assigned to fixed size literal
error message
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-10-30 10:58:25 PDT ---
This is a spinoff of Issue 8893
struct Foo {
char[3] data;
}
int bar(Foo f) {
return f.data[0];
}
void main() {
enum f = Foo(['A', 'B']);
enum int b = bar(f);
}
Expected error message:
test.d(8): Error: cannot implicitly convert expression (['A','B']) of type
char[] to char[3]
But DMD 2.061alpha gives:
test.d(8): Error: cannot implicitly convert expression (['A','B']) of type
char[] to char
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8893] [ICE][CTFE] (interpret.c, line 3598) with failed array access
http://d.puremagic.com/issues/show_bug.cgi?id=8893 --- Comment #5 from bearophile_h...@eml.cc 2012-10-30 10:58:55 PDT --- (In reply to comment #4) The error message seems not correct: Moved to Issue 8918 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910 --- Comment #10 from Daniel Cousens daniel...@bigpond.com 2012-10-30 14:04:16 PDT --- (In reply to comment #9) Frankly thats a terrible alternative. Perhaps static array specialisations are in order then; assuming current implementations can't be modified to suit. So, you think that copying a static array is a good idea? Because that's what on overload for a static array would do. And all that overload could do would be to slice the static array and pass it to the normal overload (because static arrays are _not_ ranges and _cannot_ be, because you can't pop any of their elements off), which would lead to the slice being completely invalid once the function returned, meaning that the result would be completely unsafe and invalid. So no, that wouldn't work. I do think it is a good idea, no, but that was the clearest solution... second to that proposed by Timon: map!(c = c[])(cs[]).join(,); But if what you say is set in stone, then there is no point taking it further. Maybe other than the fact putting something in the documentation/compiler warning so that the error message that is given is not so confusing to those coming from other languages. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910 --- Comment #11 from Daniel Cousens daniel...@bigpond.com 2012-10-30 14:05:00 PDT --- (In reply to comment #9) Frankly thats a terrible alternative. Perhaps static array specialisations are in order then; assuming current implementations can't be modified to suit. So, you think that copying a static array is a good idea? Because that's what on overload for a static array would do. And all that overload could do would be to slice the static array and pass it to the normal overload (because static arrays are _not_ ranges and _cannot_ be, because you can't pop any of their elements off), which would lead to the slice being completely invalid once the function returned, meaning that the result would be completely unsafe and invalid. So no, that wouldn't work. I do not think it is a good idea, no, but that was the clearest solution... second to that proposed by Timon. map!(c = c[])(cs[]).join(,); But if what you say is unchanging, then there is no point taking it further. Maybe putting something in the documentation/compiler warning so that the error message that is given is not so confusing to those coming from other languages could help. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910 --- Comment #12 from Daniel Cousens daniel...@bigpond.com 2012-10-30 14:06:48 PDT --- Sigh, ignore comment 10... (or delete it, and this) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910 --- Comment #14 from timon.g...@gmx.ch 2012-10-30 14:13:48 PDT --- (In reply to comment #11) ... map!(c = c[])(cs[]).join(,); ... This is not valid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910
--- Comment #13 from timon.g...@gmx.ch 2012-10-30 14:12:53 PDT ---
(In reply to comment #9)
Frankly thats a terrible alternative. Perhaps static array specialisations
are
in order then; assuming current implementations can't be modified to suit.
So, you think that copying a static array is a good idea? Because that's what
on overload for a static array would do. ...
auto rangeFunction(T)(ref T range) if(isStaticArray!T ...){
return rangeFunction(range[]);
}
I do not think implicitly slicing static arrays for all range-based functions
is really worth the trouble. It would silence all those fruitless discussions
though.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910 --- Comment #15 from Daniel Cousens daniel...@bigpond.com 2012-10-30 14:17:44 PDT --- (In reply to comment #14) (In reply to comment #11) ... map!(c = c[])(cs[]).join(,); ... This is not valid. Huh. So it isn't, it compiles however, just garbage output. What *is* it doing differently? Also, thanks for bearing with me on this Jonathan M Davis, you're explanation has been a great helping in understanding the problem. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910 --- Comment #16 from bearophile_h...@eml.cc 2012-10-30 14:20:00 PDT --- (In reply to comment #9) So, you think that copying a static array is a good idea? Because that's what on overload for a static array would do. And all that overload could do would be to slice the static array and pass it to the normal overload (because static arrays are _not_ ranges and _cannot_ be, because you can't pop any of their elements off), which would lead to the slice being completely invalid once the function returned, meaning that the result would be completely unsafe and invalid. So no, that wouldn't work. This bug report is about a join() that works with fixed-size matrix. join() is supposed to allocate a new array as large as the sum of the rows plus the optional separators. And if this join function is well written (taking fixed sized array by reference and not using the dynamic-array function badly as you say), the result is correct and the requested computation is done efficiently, it's more efficient than the case with dynamic arrays, because there is less indirection and being all the rows of the same length there is no need to read and use every length of each row as in the dynamic array case, because it's surely rectangular. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910 --- Comment #18 from timon.g...@gmx.ch 2012-10-30 14:24:25 PDT --- (In reply to comment #15) (In reply to comment #14) (In reply to comment #11) ... map!(c = c[])(cs[]).join(,); ... This is not valid. Huh. So it isn't, it compiles however, just garbage output. What *is* it doing differently? ... This copies the static arrays to a function-local parameter, slices them and returns those slices. i.e. it escapes stack addresses. It should be a compile error. Mine implicitly slices the original static arrays before they are passed in and returns those slices. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8910] Static arrays, dynamic arrays and std.array.join
http://d.puremagic.com/issues/show_bug.cgi?id=8910 --- Comment #19 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-30 15:59:40 PDT --- Slicing static arrays is unsafe (and really should be considered to be @system - issue# 8838), so it really shouldn't be happening silently. If it were up to me, static arrays would _never_ be implicitly sliced precisely because of how dangerous it is. It's useful and should be permitted, but it should be explicit. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8839] MmFile do not use Range
http://d.puremagic.com/issues/show_bug.cgi?id=8839 --- Comment #7 from bioinfornatics bioinfornat...@gmail.com 2012-10-30 16:05:44 PDT --- Since slicing use void[] as return type instead ubyte you can't use UFCS you need to cast it length member should be maybe size_t i think design this module should be a good thing. If you break something is a minor break but you will get a better mmFile -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8839] MmFile do not use Range
http://d.puremagic.com/issues/show_bug.cgi?id=8839 --- Comment #9 from bioinfornatics bioinfornat...@gmail.com 2012-10-30 16:26:08 PDT --- about breaking change i understand is important to D to get an api more stable about ufcs: - do not works _file[_currentPosition .. _file.length] .countUntil!( ( a ) = isWhite( cast(dchar) a ) ); - works countUntil!( ( a ) = isWhite( cast(dchar) a ) ) ( cast(ubyte[]) _file[_currentPosition .. _file.length] ); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8839] MmFile do not use Range
http://d.puremagic.com/issues/show_bug.cgi?id=8839 --- Comment #10 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-30 16:31:46 PDT --- Then save the range as a variable and use UFCS on that, or this would probably work: (cast(ubyte[])_file[_currentPosition .. _file.length]).countUntil!(a = isWhite(a))(); I really don't see not being able to use UFCS on the slice directly as a big deal. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8839] MmFile do not use Range
http://d.puremagic.com/issues/show_bug.cgi?id=8839 --- Comment #11 from bioinfornatics bioinfornat...@gmail.com 2012-10-30 16:40:25 PDT --- for me that is ok but for new developer it could be little confused since in first it will try the common ufcs approach. It will get a strange template error about as void[] is used as return type. It will spent some time before fond a way as in this special case he need to cast it. So for me is ok but for others maybe add a little example with a ufcs approach to help him ;-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1323] Implement opIn_r for arrays
http://d.puremagic.com/issues/show_bug.cgi?id=1323 --- Comment #15 from Roy Crihfield rscr...@gmail.com 2012-10-30 21:32:47 PDT --- I think this absolutely needs to be reconsidered. The success of the same semantics in Python should be enough proof of the convenience and low risk of this feature. On top of that, the `in' operator is overloadable anyway, meaning it already has semantic ambiguity for different types. Should `~' be considered an issue since it can accept both T and T[]? Practicality seems preferable here. I think this should be reopened. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1323] Implement opIn_r for arrays
http://d.puremagic.com/issues/show_bug.cgi?id=1323 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #16 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-30 22:00:03 PDT --- I think this absolutely needs to be reconsidered. The success of the same semantics in Python should be enough proof of the convenience and low risk of this feature. On top of that, the `in' operator is overloadable anyway, meaning it already has semantic ambiguity for different types. Should `~' be considered an issue since it can accept both T and T[]? Practicality seems preferable here. I think this should be reopened. We care a lot more about efficiency than python does, and we hold to one of the key concepts that C++ does - that certain operators and operations need to have a maximum algorithmic complexity. A prime example of this is std.container. All of the common operations have a maximum algorithmic complexity, and any container which can't implement them with tha complexity, doesn't have them. For instance, SList and DList don't have a length property, because they can't implement it in O(1). The same goes for range-base operations. front, popFront, length, slicing, etc. have to be O(1). If they can't be, then they're not implemented. That's why narrow strings aren't sliceable, have no length, and don't provide random access. They can't do it in O(1). In the case of in, it's required to have at most O(log n), which is what it takes to search for an element in a balanced binary tree. AAs can do it in O(1), which is even better, so they get in. Dynamic arrays require O(n), which is worse than O(log n), so they don't have it and never will. If we allowed them to have in, then functions could not rely on in's algorithmic complexity, which would make it useless for generic code. Of course, it's true that anyone can overload an operator or define a function which has worse algorithmic complexity than it's required to have (e.g. they define length on a range which has to count all of its elements to get its length, making it O(n) instead of the required O(1)), but in that case, the programmer screwed up, and it's their fault when algorithms using their type have horrible performance. But as long as they implement those functions with the correct algorithmic complexity, then algorithms using those functions can guarantee a certain level of performance. They can't do that if they can't rely on the maximum algorithmic complexity of the functions and operations that they use. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7177] $ should forward to length by default
http://d.puremagic.com/issues/show_bug.cgi?id=7177 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #7 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-30 22:07:29 PDT --- It would be great to be able to rely on $ working with slicing with any range type, but right now, that would require that all sliceable ranges overload opDollar, which obviously isn't the case right now and is arguably unreasonable to expect (especially given the boilerplate involved). So, if we're going to require that $ work with slicing (which we really should do), then this proposal is pretty much required. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2630] ddoc should be able to document unittests
http://d.puremagic.com/issues/show_bug.cgi?id=2630 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-30 22:42:22 PDT --- (In reply to comment #2) Implementing ddoc'ed unittests entails that each unittest must have an owner (the preceding declaration) to put it in the right HTML tag. That would also solve the unittest name problem (bug 2749) with 'owner.stringof'. A simple workaround is to look for the next element in the members list to see if it's a unittest declaration. If it is, and it's commented and not private, we can insert a %s code block in the previous element. This would be done until a non-unittest block is found, or until a private/non-commented one is found. It's a ~20-line change to implement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
