[Issue 7361] No documentation for front tuple expansion in foreach over range
https://issues.dlang.org/show_bug.cgi?id=7361 Vlad Levenfeld vlevenf...@gmail.com changed: What|Removed |Added CC||vlevenf...@gmail.com --
[Issue 9449] Static arrays of 128bit types segfault on initialization. Incorrect calling of memset128ii.
https://issues.dlang.org/show_bug.cgi?id=9449
dbr dbugrepor...@gmail.com changed:
What|Removed |Added
CC||dbugrepor...@gmail.com
--- Comment #28 from dbr dbugrepor...@gmail.com ---
This still segfaults with dmd 2.066 (64-bit linux):
void main() {
float[4][2] m = [[2.0, 1, 3, 4], [2.0, 1, 3, 4]];
}
Dump of assembler code for function _Dmain:
0x0041a160 +0:push rbp
0x0041a161 +1:movrbp,rsp
0x0041a164 +4:subrsp,0x40
0x0041a168 +8:learax,[rbp-0x30]
0x0041a16c +12:movabs rsi,0x2
0x0041a176 +22:movss xmm0,DWORD PTR [rip+0x183e2]#
0x432560
0x0041a17e +30:movss DWORD PTR [rbp-0x10],xmm0
0x0041a183 +35:movecx,0x3f80
0x0041a188 +40:movDWORD PTR [rbp-0x40],ecx
0x0041a18b +43:movss xmm1,DWORD PTR [rbp-0x40]
0x0041a190 +48:movss DWORD PTR [rbp-0xc],xmm1
0x0041a195 +53:movss xmm2,DWORD PTR [rip+0x183c7]#
0x432564
0x0041a19d +61:movss DWORD PTR [rbp-0x8],xmm2
0x0041a1a2 +66:movss xmm3,DWORD PTR [rip+0x183be]#
0x432568
0x0041a1aa +74:movss DWORD PTR [rbp-0x4],xmm3
0x0041a1af +79:leardi,[rbp-0x10]
0x0041a1b3 +83:push QWORD PTR [rdi+0x8]
0x0041a1b6 +86:push QWORD PTR [rdi]
0x0041a1b8 +88:movrdi,rax
0x0041a1bb +91:call 0x41ad5c _memset128ii
0x0041a1c0 +96:addrsp,0x10
0x0041a1c4 +100:xoreax,eax
0x0041a1c6 +102:leave
0x0041a1c7 +103:ret
--
[Issue 7361] No documentation for front tuple expansion in foreach over range
https://issues.dlang.org/show_bug.cgi?id=7361 --- Comment #2 from bearophile_h...@eml.cc --- So I think it's better to not document this anti-feature. --
[Issue 4374] Required do-while ending semicolon
https://issues.dlang.org/show_bug.cgi?id=4374 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c59ca10f14c9e96fd7c9ab0ae53c242c4622ff47 Fix Issue 4374 - Required do-while ending semicolon Deprecation - Error https://github.com/D-Programming-Language/dmd/commit/8d7b4d13e71e50769f27bad64eeaf6a9dec7f197 Merge pull request #3929 from yebblies/issue4374 Issue 4374 - Required do-while ending semicolon --
[Issue 2656] Remove octal literals
https://issues.dlang.org/show_bug.cgi?id=2656 --- Comment #23 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/24574355a5b44399641054c62ff5e7e65a55153a Fix Issue 2656 - Remove octal literals Deprecation - Error https://github.com/D-Programming-Language/dmd/commit/c50c52d927c84d5bc523a781a2a837d1100a3ae6 Merge pull request #3916 from yebblies/issue2656 Issue 2656 - Remove octal literals --
[Issue 13383] wrong code with -O with ints, longs and bitwise operations
https://issues.dlang.org/show_bug.cgi?id=13383 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||pull CC||yebbl...@gmail.com Assignee|nob...@puremagic.com|yebbl...@gmail.com OS|Windows |All --- Comment #2 from yebblies yebbl...@gmail.com --- The compiler incorrectly optimizes 1L (1L k) to 1 btst k, which is only valid when 1L fits in a register. https://github.com/D-Programming-Language/dmd/pull/3934 --
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Hardware|x86 |All OS|Windows |All --- Comment #1 from yebblies yebbl...@gmail.com --- I agree. --
[Issue 7361] No documentation for front tuple expansion in foreach over range
https://issues.dlang.org/show_bug.cgi?id=7361 --- Comment #3 from Vlad Levenfeld vlevenf...@gmail.com --- I'm not sure its such an anti-feature - I keep having cannot infer argument types bugs using foreach on custom ranges, and zipping them with an enumeration sequence beforehand seems a pleasant nice enough workaround. (To be fair this may be fixed in 2.067 but I don't know because 2.067 segfaults on my codebase and I haven't had time to hunt down the cause yet.) In any case I feel it should either be documented or removed because it caught me by surprise and took a little bit of time to figure out what was going on, mainly because the lack of documentation. --
[Issue 9817] Syntax change for front tuple expansion in foreach
https://issues.dlang.org/show_bug.cgi?id=9817 Vlad Levenfeld vlevenf...@gmail.com changed: What|Removed |Added CC||vlevenf...@gmail.com --
[Issue 13404] heap-allocating a struct passes TypeInfo_Pointer to the GC, not TypeInfo_struct
https://issues.dlang.org/show_bug.cgi?id=13404 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/d0bba643e9a6c40c56d84098ae024fde6eed9a66 Merge pull request #941 from rainers/fix_13404 Issue 13404 - heap-allocating a struct passes TypeInfo_Pointer to the GC, not TypeInfo_struct --
[Issue 13407] New: Better error message for static array size overflow
https://issues.dlang.org/show_bug.cgi?id=13407
Issue ID: 13407
Summary: Better error message for static array size overflow
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
This program:
enum N = 9;
long[1 N][1 N][N][N] a;
void main() {}
With dmd 2.067alpha gives the error messages:
test.d(2,28): Error: index 9 overflow for static array
test.d(2,28): Error: index 9 overflow for static array
This means that the array is too much large for a statically allocated array,
but I think the meaning error message is not clear enough. So I suggest
something more similar to (a single error message):
test.d(2,28): Error: array 'a' is too much large (512 * 512 * 9 * 9 of 'long')
to be allocated statically.
In such cases you usually replace the static array with a heap-allocated array,
like:
enum N = 9;
long[][][][] a;
void main() {
a = new typeof(a)(1 N, 1 N, N, N);
}
But this generates a very large number of dynamic arrays that waste time and
efficiency and stress the garbage collector.
So often a better data structure is an array that has dynamic only one or more
of the last coordinates:
enum N = 9;
long[1 N][1 N][][] a;
void main() {
a = new typeof(a)(N, N);
}
Unfortunately I think the error message can't explain this idiom to the user.
--
[Issue 13407] Better error message for static array size overflow
https://issues.dlang.org/show_bug.cgi?id=13407 --- Comment #1 from bearophile_h...@eml.cc --- (In reply to bearophile_hugs from comment #0) test.d(2,28): Error: array 'a' is too much large (512 * 512 * 9 * 9 of 'long') to be allocated statically. Or even: test.d(2,28): Error: array 'a' is too much large (512 * 512 * 9 * 9 = 21_233_664 of 'long') to be allocated statically. --
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381
--- Comment #2 from bearophile_h...@eml.cc ---
Given this code:
void foo(uint[] a) @nogc {
if (a == [1, 2]) {}
}
One way to rewrite it is (the immutable can't be always used):
void foo(uint[] a) @nogc {
immutable static uint[2] __foo_aux0 == [1, 2];
if (a == __foo_aux0) {}
}
Or more efficient:
void foo(uint[] a) @nogc {
if (a.length == 2 a[0] == 1 a[1] == 2) {}
}
--
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381 --- Comment #3 from yebblies yebbl...@gmail.com --- (In reply to bearophile_hugs from comment #2) One way to rewrite it is (the immutable can't be always used): While re-writes are certainly the simplest way to explain it, using them in the compiler often leads to complications, especially with error messages referring to the re-written code instead of the original. For this case, and similar cases, the compiler can simply type the array literal as a static array, because it knows that == can't escape any references. It already does something like this for indexing array literals. --
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381
--- Comment #4 from bearophile_h...@eml.cc ---
(In reply to yebblies from comment #3)
For this case, and similar cases, the compiler can simply type the array
literal as a static array, because it knows that == can't escape any
references. It already does something like this for indexing array literals.
I see. I have suggested a rewrite like this:
if (a.length == 2 a[0] == 1 a[1] == 2) {}
Because most array literals used for equality or comparison are short or very
short, so calling == or on few single items is much more efficient than
calling a runtime function that works on whole arrays.
--
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381
--- Comment #5 from yebblies yebbl...@gmail.com ---
(In reply to bearophile_hugs from comment #4)
(In reply to yebblies from comment #3)
For this case, and similar cases, the compiler can simply type the array
literal as a static array, because it knows that == can't escape any
references. It already does something like this for indexing array
literals.
I see. I have suggested a rewrite like this:
if (a.length == 2 a[0] == 1 a[1] == 2) {}
Because most array literals used for equality or comparison are short or
very short, so calling == or on few single items is much more efficient
than calling a runtime function that works on whole arrays.
Ideally the optimizer would do this by itself, once the literal is
stack-allocated. I suspect it already does in some cases for gdc/ldc.
--
[Issue 13400] Linking problems with bigints and std.functional.memoize
https://issues.dlang.org/show_bug.cgi?id=13400 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1787f89d9f0460b3fc34b90e0c49a57475923a30 fix Issue 13400 - Linking problems with bigints and std.functional.memoize https://github.com/D-Programming-Language/dmd/commit/991ce9187dcdae9745065f168b531121b02d5371 Merge pull request #3932 from 9rnsr/fix13400 [REG2.067a] Issue 13400 - Linking problems with bigints and std.functional.memoize --
[Issue 13400] Linking problems with bigints and std.functional.memoize
https://issues.dlang.org/show_bug.cgi?id=13400 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381
--- Comment #6 from bearophile_h...@eml.cc ---
(In reply to yebblies from comment #5)
Ideally the optimizer would do this by itself, once the literal is
stack-allocated. I suspect it already does in some cases for gdc/ldc.
If I compile this program:
bool foo(in int[] a) {
return a == [1, 2, 3];
}
void main() {}
With the latest ldc2 with:
ldmd2 -O -release -inline -noboundscheck -output-s test.d
The asm of foo is:
__D4test3fooFxAiZb:
subl$20, %esp
movl$3, 4(%esp)
movl$__D12TypeInfo_xAi6__initZ, (%esp)
calll __d_newarrayvT
movl$3, 8(%edx)
movl$2, 4(%edx)
movl$1, (%edx)
movl%edx, 12(%esp)
movl%eax, 8(%esp)
movl28(%esp), %eax
movl%eax, 4(%esp)
movl24(%esp), %eax
movl%eax, (%esp)
movl$__D12TypeInfo_Axi6__initZ, 16(%esp)
calll __adEq2
testl %eax, %eax
setne %al
addl$20, %esp
ret $8
--
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381 --- Comment #7 from yebblies yebbl...@gmail.com --- (In reply to bearophile_hugs from comment #6) (In reply to yebblies from comment #5) Ideally the optimizer would do this by itself, once the literal is stack-allocated. I suspect it already does in some cases for gdc/ldc. If I compile this program: Like I said, once the literal is stack-allocated it's more likely to work. --
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381
--- Comment #8 from bearophile_h...@eml.cc ---
(In reply to yebblies from comment #7)
Like I said, once the literal is stack-allocated it's more likely to work.
OK, another experiment:
bool foo(in int[] a) {
immutable static int[3] aux = [1, 2, 3];
return a == aux;
}
void main() {}
__D4test3fooFxAiZb:
subl$20, %esp
movl28(%esp), %eax
movl%eax, 4(%esp)
movl24(%esp), %eax
movl%eax, (%esp)
movl$__D12TypeInfo_Axi6__initZ, 16(%esp)
movl$__D4test3fooFxAiZb3auxyG3i, 12(%esp)
movl$3, 8(%esp)
calll __adEq2
testl %eax, %eax
setne %al
addl$20, %esp
ret $8
--
[Issue 13408] New: template mixins allows to declare duplicates
https://issues.dlang.org/show_bug.cgi?id=13408
Issue ID: 13408
Summary: template mixins allows to declare duplicates
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: temta...@gmail.com
import std.stdio;
mixin template R() {
~this() { write(1); }
}
struct S {
mixin R;
~this() { write(2); }
}
void main() {
S s;
}
This code compiles OK and prints 21 when it should NOT.
import std.stdio;
mixin template R() {
int a = 1;
void foo() { write(a); }
}
struct S {
mixin R;
void bar() { write(a); }
int a = 2;
}
void main() {
S s;
s.foo();
s.bar();
}
This code also compiles OK and prints 12 when it's strange and bug-prone.
--
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381
--- Comment #9 from yebblies yebbl...@gmail.com ---
(In reply to bearophile_hugs from comment #8)
(In reply to yebblies from comment #7)
Like I said, once the literal is stack-allocated it's more likely to work.
OK, another experiment:
bool foo(in int[] a) {
immutable static int[3] aux = [1, 2, 3];
return a == aux;
}
void main() {}
__D4test3fooFxAiZb:
subl$20, %esp
movl28(%esp), %eax
movl%eax, 4(%esp)
movl24(%esp), %eax
movl%eax, (%esp)
movl$__D12TypeInfo_Axi6__initZ, 16(%esp)
movl$__D4test3fooFxAiZb3auxyG3i, 12(%esp)
movl$3, 8(%esp)
calll __adEq2
testl %eax, %eax
setne %al
addl$20, %esp
ret $8
Which compiler? I'd say it's worth filing an optimizer enhancement.
--
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381 --- Comment #10 from bearophile_h...@eml.cc --- (In reply to yebblies from comment #9) Which compiler? The latest ldc2, version 0.14.0 (DMD v2.065, LLVM 3.4.2). dmd is not doing better. I don't know what gdc does in this case. I'd say it's worth filing an optimizer enhancement. I don't know. --
[Issue 13381] One case of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381 --- Comment #11 from yebblies yebbl...@gmail.com --- (In reply to bearophile_hugs from comment #10) dmd is not doing better. Haha no surprise there. I'd say it's worth filing an optimizer enhancement. I don't know. Actually this is the same thing as general inlining and expanding of array ops, which I think you've already filed. --
[Issue 3713] Tail call optimization not enabled with the ?: operator
https://issues.dlang.org/show_bug.cgi?id=3713 yebblies yebbl...@gmail.com changed: What|Removed |Added Assignee|yebbl...@gmail.com |nob...@puremagic.com --
[Issue 2350] Contracts with a naked body are indecent
https://issues.dlang.org/show_bug.cgi?id=2350 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||pull CC||yebbl...@gmail.com Hardware|x86 |All Version|D1 |D1 D2 Assignee|nob...@puremagic.com|yebbl...@gmail.com OS|Windows |All --- Comment #3 from yebblies yebbl...@gmail.com --- Pull to generate an error. https://github.com/D-Programming-Language/dmd/pull/3937 --
[Issue 10124] Array length increases on subtraction of a big number instead of throwing RangeError
https://issues.dlang.org/show_bug.cgi?id=10124 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com --- I'm not sure it should fail. This is how unsigned types usually work. --
[Issue 5017] Access Violation when calling a template function of outer class (from inner one)
https://issues.dlang.org/show_bug.cgi?id=5017 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Hardware|Other |All Resolution|--- |WORKSFORME OS|Windows |All --- Comment #1 from yebblies yebbl...@gmail.com --- I can't reproduce this with 2.067 HEAD --
[Issue 1517] (D1 only) .sort for structs behaves badly with ref opCmp
https://issues.dlang.org/show_bug.cgi?id=1517 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Hardware|x86 |All Summary|.sort for structs behaves |(D1 only) .sort for structs |badly with ref opCmp|behaves badly with ref ||opCmp OS|Windows |All --- Comment #3 from yebblies yebbl...@gmail.com --- I get object.Error@(0): TypeInfo.compare is not implemented On recent dmd (2.067 HEAD), and given that builtin .sort is going away this is WONTFIX for D2. --
[Issue 7099] (D1 only) static constructor in template mixin in library not executed
https://issues.dlang.org/show_bug.cgi?id=7099 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Version|D1 D2 |D1 Summary|static constructor in |(D1 only) static |template mixin in library |constructor in template |not executed|mixin in library not ||executed --- Comment #3 from yebblies yebbl...@gmail.com --- I can't reproduce this on recent D2 (2.067 HEAD win32) --
[Issue 6423] Garbage is returned from `void main()`
https://issues.dlang.org/show_bug.cgi?id=6423 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||pull CC||yebbl...@gmail.com Hardware|Other |All OS|Windows |All --- Comment #5 from yebblies yebbl...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3938 --
[Issue 6423] Garbage is returned from `void main()`
https://issues.dlang.org/show_bug.cgi?id=6423 yebblies yebbl...@gmail.com changed: What|Removed |Added Assignee|nob...@puremagic.com|yebbl...@gmail.com --
[Issue 13379] Latest dmd fails with recursive template expansion in std.regex
https://issues.dlang.org/show_bug.cgi?id=13379 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/5efa203c22ba4b49f2366f71d1104c2aaf37b144 fix Issue 13379 - Latest dmd fails with recursive template expansion in std.regex https://github.com/D-Programming-Language/dmd/commit/178d02e1dac49ba9ac301183037146c5d8d68e2a Merge pull request #3905 from 9rnsr/fix13379 [REG2.067a] Issue 13379 - Latest dmd fails with recursive template expansion in std.regex --
[Issue 13394] invariant fail to link since 2.066 when using separate compilation
https://issues.dlang.org/show_bug.cgi?id=13394 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/7683136e580c73fa6aa150c4c3ea4b54ed6f9b32 fix Issue 13394 - invariant fail to link since 2.066 when using separate compilation https://github.com/D-Programming-Language/dmd/commit/f6c130e66791ba9eb047334dec0645d06e74cc89 Merge pull request #3918 from 9rnsr/fix13394 [REG2.066] Issue 13394 - invariant fail to link since 2.066 when using separate compilation --
[Issue 13394] invariant fail to link since 2.066 when using separate compilation
https://issues.dlang.org/show_bug.cgi?id=13394 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13409] New: std.range.padLeft/Right
https://issues.dlang.org/show_bug.cgi?id=13409 Issue ID: 13409 Summary: std.range.padLeft/Right Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: peter.alexander...@gmail.com Would be useful to have two new higher-order ranges in std.range: padLeft(R, E)(R r, E e, size_t n) if (isInputRange!R hasLength!R !is(CommonType!(ElementType!R, E) == void)) padRight(R, E)(R r, E e, size_t n) is (isInputRange!R !is(CommonType!(ElementType!R, E) == void)) padLeft returns a range that is padded on the left up to 'n' elements with 'e', and padRight pads on the right. Example: int[] a = [1, 2, 3]; padLeft(a, 0, 5) == [0, 0, 1, 2, 3] padRight(a, 0, 5) == [1, 2, 3, 0, 0] Notes: * If r.length = n then neither add any padding, and just iterates r. * padLeft requires hasLength, but padRight does not. * If R is forward, then so will padLeft/Right * If R is bidirectional, and hasLength, then so will padLeft/Right * If R is random access, and hasLength, then so will padLeft/Right * If R is infinite, padLeft/Right will return r and be type R. --
[Issue 10124] Array length increases on subtraction of a big number instead of throwing RangeError
https://issues.dlang.org/show_bug.cgi?id=10124 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #2 from monarchdo...@gmail.com --- (In reply to yebblies from comment #1) I'm not sure it should fail. This is how unsigned types usually work. Yeah... but it's not actually an arithmetic operations here. It's a setter operation. AFAIK, array resize detects overflow. I don't see why it wouldn't detect underflow? Just saying. --
[Issue 13409] std.range.padLeft/Right
https://issues.dlang.org/show_bug.cgi?id=13409 --- Comment #2 from Peter Alexander peter.alexander...@gmail.com --- (In reply to monarchdodra from comment #1) Is there a use case for this outside of string formatting? I need it for padding data buffers out. Also, does it justify having a new range, when the same end result could be had with chain and repeat? I think it is justified. When using chain/repeat, it isn't immediately clear what you are doing, whereas padLeft/Right are self documenting. If I needed to do this, I would create padLeft/Right myself as separate functions to make it clear. If people are going to do this then it might as well be in Phobos, in my opinion. Also, padRight with an input range without length cannot be implemented in terms of other ranges, I think (not easily anyway). I actually only need padRight, but I feel padLeft should exist for symmetry. For padLeft, I'm making the assumption that r is random access. If we want to accept forward range (input is not possible), then we have to use r.save.walkLength(), presuming the extra complexity is acceptable. The only case where your proposal could make sense, is for padRight on a pure input range (no length, no save). But that's one hell of a particular case... Random access is unnecessary. You only need hasLength + input range (see proposal). Incidentally, these kind of subtleties are a good reason why Phobos should provide them instead of relying on users to do so. The case for input range with no length for padRight is actually exactly what prompted me to create this. I'm generating some data of unknown length (it is lazily generated) that I want to copy into a pre-sized buffer, and then fill the rest of the buffer with 0's. --
[Issue 13403] [ICE][2.067Alpha] Internal error: backend\type.c 332 with new package protection extension.
https://issues.dlang.org/show_bug.cgi?id=13403 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3940 --
