[Issue 17954] New: init member should be disallowed
https://issues.dlang.org/show_bug.cgi?id=17954 Issue ID: 17954 Summary: init member should be disallowed Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: schvei...@yahoo.com Now that Phobos and DMD do not have any types that define an init member of any kind (TypeInfo.init was the only culprit), we should disallow defining members with the name init. This allows generic code to correctly assume that T.init will be the exact default initializer instance of a type. I propose that in the next compiler release (at time of this writing, that would be 2.078) defining an init member should be a deprecation warning. Then at the next compiler release, it is an error. --
[Issue 17944] MSCOFF: debug info not compatible with LLVMs LLD
https://issues.dlang.org/show_bug.cgi?id=17944 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/d75aaa258f155bd98004e8658e8921b7dba8bd51 fix issue 17944: MSCOFF: do not write empty debug$S section https://github.com/dlang/dmd/commit/775fce733b705a257a905015b781cb9cd40ffca8 Merge pull request #7253 from rainers/lazy_debugS fix issue 17944: MSCOFF: do not write empty debug$S section merged-on-behalf-of: Walter Bright --
[Issue 17953] New: inout-like mechanism to infer function attributes from callback attributes
https://issues.dlang.org/show_bug.cgi?id=17953 Issue ID: 17953 Summary: inout-like mechanism to infer function attributes from callback attributes Product: D Version: D2 Hardware: Other OS: Other Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Not being able to correctly attribute methods is a common issue when designing interfaces and classes. While it's often still possible to restrict all derived classes to certain attributes, it's a lot harder to restrict all possible callbacks. void toString(scope void delegate(in char[]) @wildcard) @(wildcard nogc safe); It would be a great help if such a method could be defined, to that @nogc, @safe, pure, and nothrow can be made dependent on the passed in callback, making it possible to call the method in @nogc code, while also passing in a GC using callback. --
[Issue 5351] Add template mixin for Range Primitives using random access
https://issues.dlang.org/show_bug.cgi?id=5351
Simen Kjaeraas changed:
What|Removed |Added
CC||simen.kja...@gmail.com
--- Comment #3 from Simen Kjaeraas ---
The implementation above will fail for this simple case:
MyRange!int a = [1,2,3];
a.popFront();
assert(a[0] == a.front);
It could be made to work for ranges that support slicing, and assignment from
the slice to the range:
void popFront() {
this = this[1..$];
}
front and empty are then trivial calls to this[0] and length == 0,
respectively.
One option that only requires opIndex and length would use a wrapper struct.
This solution would leave MyRange as a non-range, though - only its sliced
result would be a range:
struct MyRange(T) {
T[] arr;
T opIndex(size_t idx) {
return arr[idx];
}
@property
size_t length() {
return arr.length;
}
mixin rangeFuncs!();
}
template rangeFuncs() {
auto opSlice() {
alias TT = typeof(this);
struct Result {
size_t _index;
TT* _range;
auto front() {
return (*_range)[_index];
}
@property
bool empty() {
return _index == _range.length;
}
void popFront() {
_index++;
}
auto opIndex(size_t idx) {
return (*_range)[_index + idx];
}
}
Result result;
result._range = &this;
return result;
}
}
unittest {
import std.range.primitives : isInputRange;
import std.algorithm.comparison : equal;
auto a = MyRange!int([1,2,3,4]);
static assert(!isInputRange!(typeof(a)));
static assert(isInputRange!(typeof(a[])));
assert(a[].equal([1,2,3,4]));
}
In conclusion, opIndex + length is insufficient functionality to turn something
into a range.
--
[Issue 17851] htonl already defined in phobos64.lib
https://issues.dlang.org/show_bug.cgi?id=17851 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/cf8ed256f956f1fb551c314881922b8fc817246b core.sys.windows.winsock2: Don't implement htons() etc. To prevent duplicate symbols when pulling in that object file and the implementations in the ws2_32 library during linking. fix issue 17851 and https://github.com/ldc-developers/ldc/issues/468 --
[Issue 17952] std.range.transposed save is invalid
https://issues.dlang.org/show_bug.cgi?id=17952 Alexandru Razvan Caciulescu changed: What|Removed |Added CC||alexandru.razva...@gmail.co ||m Assignee|nob...@puremagic.com|alexandru.razva...@gmail.co ||m --
[Issue 17952] std.range.transposed save is invalid
https://issues.dlang.org/show_bug.cgi?id=17952 --- Comment #2 from Steven Schveighoffer --- To ensure this test case is checking the right issue, change the third line to: assert(y.equal([[1,4],[2,5],[3,6]])); And get rid of the y.popFront. Clearly, we should be able to iterate y without iterating x. But that's not what happens (consuming any saved range consumes them all). --
[Issue 17952] std.range.transposed save is invalid
https://issues.dlang.org/show_bug.cgi?id=17952 --- Comment #1 from Steven Schveighoffer --- Scratch that, x is not really [[2,5],[3,6]], it's an empty range! Just using equals destroys it. transposed clearly isn't even close to a forward range. --
[Issue 17256] Inconsistent output between json and ddoc
https://issues.dlang.org/show_bug.cgi?id=17256 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17256] Inconsistent output between json and ddoc
https://issues.dlang.org/show_bug.cgi?id=17256 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/608b82452befcd6463106b68e6c1b3e40887597c fix Issue 17256 - Inconsistent output between json and ddoc JSON should include version blocks in templates, same as ddoc. --
[Issue 17607] not an associative array initializer
https://issues.dlang.org/show_bug.cgi?id=17607
John Colvin changed:
What|Removed |Added
CC||john.loughran.colvin@gmail.
||com
--- Comment #1 from John Colvin ---
Another simpler case of this:
struct S
{
//Error: not an associative array initializer
D a = ["fdsa": ["fdsafd": "fdsfa"]];
// OK
D b = (["fdsa": ["fdsafd": "fdsfa"]]);
}
struct D
{
this(string[string][string]) {}
}
Andre, perhaps putting brackets around it is a workaround for you as well?
--
[Issue 17952] New: std.range.transposed save is invalid
https://issues.dlang.org/show_bug.cgi?id=17952 Issue ID: 17952 Summary: std.range.transposed save is invalid Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: schvei...@yahoo.com auto x = [[1,2,3],[4,5,6]].transposed; auto y = x.save; assert(x.equal([[1,4],[2,5],[3,6]])); y.popFront; assert(x.equal([[1,4],[2,5],[3,6]])); // FAILS, x is really [[2,5],[3,6]] The only way .save can truly be implemented is by duplicating the RangeOfRanges range, and there is no standard for doing this (.dup is not consistent across ranges). We have 2 options: 1. Deprecate .save (i.e. make transposed NOT a forward range) 2. convert the RangeOfRanges element to an array, and duplicate on every .save. Neither option is particularly good. My vote would be for option 1. --
[Issue 13041] std.range.transposed consumes sub-ranges
https://issues.dlang.org/show_bug.cgi?id=13041 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=17952 --
[Issue 17742] std.range.transposed does not have opIndex
https://issues.dlang.org/show_bug.cgi?id=17742 --- Comment #2 from Vladimir Panteleev --- Ouch. I didn't realize transposed works with jagged arrays. Considering this issue and that transposed doesn't work with static arrays (because they're not ranges), maybe a separate function would be better, which is closer to the matrix operation (in supporting indexing and static arrays). --
[Issue 17742] std.range.transposed does not have opIndex
https://issues.dlang.org/show_bug.cgi?id=17742 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer --- Vladimir, would appreciate your input on the PR: https://github.com/dlang/phobos/pull/5805 Currently, transposed uses `filter` to remove elements from the range transposition when the underlying column has become empty. So for instance: assert([[1,2,3], [4,5], [6,7,8]].transposed.equal([[1,4,6], [2,5,7], [3,8]]); Note the jaggedness of the range of ranges changes in weird ways, especially when holes appear in the middle. While this may be reasonable, it precludes performing opIndex on an element of the transposed result. So while transposed can be indexed if the ranges individually can be indexed, the resulting elements cannot be, making your code example unimplementable. --
[Issue 5351] Add template mixin for Range Primitives using random access
https://issues.dlang.org/show_bug.cgi?id=5351 Eduard Staniloiu changed: What|Removed |Added Keywords||bootcamp CC||edi33...@gmail.com --
[Issue 12282] Immutable result of std.array.array
https://issues.dlang.org/show_bug.cgi?id=12282 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |RESOLVED CC||and...@erdani.com Resolution|--- |WONTFIX --- Comment #5 from Andrei Alexandrescu --- Same comment as for https://issues.dlang.org/show_bug.cgi?id=5074 --
[Issue 5074] array(immutable(int)[]) ==> int[]
https://issues.dlang.org/show_bug.cgi?id=5074 Andrei Alexandrescu changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #10 from Andrei Alexandrescu --- We don't want `array` to be used to transform qualifiers on existing arrays. For arrays, the function should be identity. --
[Issue 15136] If we want toStringz to be fully correct, it needs to stop checking for '\0'
https://issues.dlang.org/show_bug.cgi?id=15136 --- Comment #4 from Steven Schveighoffer --- (In reply to Steven Schveighoffer from comment #3) > assert(s[5] == 'b'); That should have read str[5], obviously :) --
[Issue 16542] makeArray not usable with const initializer
https://issues.dlang.org/show_bug.cgi?id=16542 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/cd66c0cba650d63785ccb79a115964e6472692ca fix issue 16542 https://github.com/dlang/phobos/commit/2e9271962ffbe2cdabff8fe39be3c55121de6232 Merge pull request #5028 from somzzz/issue_16542 fix issue 16542 - makeArray not usable with const initializer --
[Issue 16542] makeArray not usable with const initializer
https://issues.dlang.org/show_bug.cgi?id=16542 github-bugzi...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
[Issue 15136] If we want toStringz to be fully correct, it needs to stop checking for '\0'
https://issues.dlang.org/show_bug.cgi?id=15136 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #3 from Steven Schveighoffer --- (In reply to John Colvin from comment #2) > It seem to me like this could happen with static arrays directly on the > stack as well, depending on what variables the compiler happens to put > directly after. It can be done with heap-allocated arrays as well: auto s = "hello".idup; auto str = s.toStringz; assert(s.ptr == str); s ~= 'b'; assert(s[5] == 'b'); The assumption that a coincidental null character after the string must mean it is part of a literal is completely unsound. Not to mention, if the null happens to be on a 4-byte boundary, then it doesn't even look at it, potentially wasting an allocation. What we really need, as Jonathan says, is a way to tell if a string pointer points at a string literal or not. This should be possible I would think, as the linker puts all the literals into the same section, no? All we have to do is check whether the array points in that section, and the null character pointer is in that section, and the null character is null. Otherwise, allocate. --
[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings
https://issues.dlang.org/show_bug.cgi?id=17914 --- Comment #10 from anonymous4 --- Judging by the code Generator can just destroy itself on termination. It's not reusable, is it? --
[Issue 17928] [scope] `in` is not treated as `const scope`
https://issues.dlang.org/show_bug.cgi?id=17928 --- Comment #3 from anonymous4 --- (In reply to Jonathan M Davis from comment #2) > Personally, I think that it was a mistake to create a storage class which > was equivalent to two other storage classes, but clearly, a number of folks > like the idea. scope const is very common, so shorthand is useful. > I suspect that a lot of folks use in simply because it looks like the > opposite of out and don't really understand what it's supposed to do. I don't think it's the case, because compiler already performed optimizations based on meaning of scope. The problem is that scope was used in a way that can't be checked by the compiler. --
[Issue 1998] std.bitarray should have setAll / opSliceAssign(bool) etc
https://issues.dlang.org/show_bug.cgi?id=1998 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/24080dfe95d9cb1fea86511e80c467be68bb7946 Fix Issue 1998 - std.bitarray should have setAll / opSliceAssign(bool) etc https://github.com/dlang/phobos/commit/876e4ccd0e3266974710f8cfb743dc3283ad774b Fix Issue 1998 - std.bitarray should have setAll / opSliceAssign https://github.com/dlang/phobos/commit/b147252785c994c26988268c7afaadbc2800405b Merge pull request #5634 from RazvanN7/Issue_1998 Fix Issue 1998 - std.bitarray should have setAll / opSliceAssign merged-on-behalf-of: Petar Kirov --
[Issue 4717] std.bitmanip.BitArray changes
https://issues.dlang.org/show_bug.cgi?id=4717 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 4717] std.bitmanip.BitArray changes
https://issues.dlang.org/show_bug.cgi?id=4717 --- Comment #11 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/7a3700135944be30279aeaec0aa32849fdc30adc Fix Issue 4717 - std.bitmanip.BitArray changes --
[Issue 1998] std.bitarray should have setAll / opSliceAssign(bool) etc
https://issues.dlang.org/show_bug.cgi?id=1998 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
