[Issue 12029] Swap on std.container.Array?
https://issues.dlang.org/show_bug.cgi?id=12029 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #3 from bb.t...@gmx.com --- swap() now works on Array: ___ void main() { import std.algorithm; import std.container: Array; auto arr = Array!int([1, 2]); swap(arr[0], arr[1]); assert(arr[0] == 2 && arr[1] == 1); }___ --
[Issue 13099] @nogc std.range.stride
https://issues.dlang.org/show_bug.cgi?id=13099 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --
[Issue 12865] splitLines returns empty array on empty string
https://issues.dlang.org/show_bug.cgi?id=12865 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |INVALID --- Comment #2 from bb.t...@gmx.com --- No your wrong Temtaime,because [``] as result would mean that the input argument contained one empty string: ___ import std.string; void main() { assert( splitLines("\n") == [``]); // ok }___ --
[Issue 5520] bitfieldsOn
https://issues.dlang.org/show_bug.cgi?id=5520 bb.t...@gmx.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #5 from bb.t...@gmx.com --- implemented in https://github.com/rtcvb32/phobos/pull/1/files --
[Issue 12861] std.algorithm.sort of core.simd.int4[] too
https://issues.dlang.org/show_bug.cgi?id=12861 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #1 from bb.t...@gmx.com --- 2.069 ok --
[Issue 12840] @nogc std.range.iota(x, y, step)
https://issues.dlang.org/show_bug.cgi?id=12840 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #1 from bb.t...@gmx.com --- 2.069 ok now --
[Issue 15296] [REG2.069] cannot inline simple function that calls use non-inlinable statements
https://issues.dlang.org/show_bug.cgi?id=15296 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/4c0c8088d34aca637aef07122ec8a26ce1244fe3 fix Issue 15296 - cannot inline simple function that calls use non-inlinable statements Add workaround to do inlining same with the old code. https://github.com/D-Programming-Language/dmd/commit/6a407df2384446cb14eea854860e391c5db59377 Merge pull request #5277 from 9rnsr/fix15296 [REG2.069] Issue 15296 - cannot inline simple function that calls use non-inlinable statements --
[Issue 15369] [REG master] id.d(369): Error: Outside Unicode code space
https://issues.dlang.org/show_bug.cgi?id=15369 Kenji Harachanged: What|Removed |Added Summary|id.d(369): Error: Outside |[REG master] id.d(369): |Unicode code space |Error: Outside Unicode code ||space --- Comment #2 from Kenji Hara --- This is git-head only regression. Same issue does not exist in 2.069.1 or earlier releases. --
[Issue 12767] writeln of a struct with toString returning char[N]
https://issues.dlang.org/show_bug.cgi?id=12767 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #3 from bb.t...@gmx.com --- 2.069 ok --
[Issue 5743] readf cannot read wchar or dchar from UTF-8 stdin
https://issues.dlang.org/show_bug.cgi?id=5743 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #3 from bb.t...@gmx.com --- 2.069, works now, test with ö and é as well. --
[Issue 13608] std.range range interfaces hide @safe-ness
https://issues.dlang.org/show_bug.cgi?id=13608 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #1 from bb.t...@gmx.com --- pass in 2.069 --
[Issue 13177] There may be a problem with std.bitmanip.BitArray and the "in" operator of associative arrays?
https://issues.dlang.org/show_bug.cgi?id=13177 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #1 from bb.t...@gmx.com --- this is the case now. you get true in your output (tba in ha) --
[Issue 15369] id.d(369): Error: Outside Unicode code space
https://issues.dlang.org/show_bug.cgi?id=15369 Kenji Harachanged: What|Removed |Added Keywords||wrong-code Severity|normal |regression --- Comment #1 from Kenji Hara --- Reduced test case (Note that the reproduction ratio is not 100%): import core.stdc.stdio; struct Msgtable { const(char)[] ident; const(char)* name; }; Msgtable[] msgtable = [ { "empty", "" }, ]; void main() { auto id = msgtable[0].ident; auto p = msgtable[0].name; printf("empty -> p = %p >>>%s<<<\n", p, p); } Introduced in: https://github.com/D-Programming-Language/dmd/pull/5220 --
[Issue 10191] std.array.array and Unicode strings
https://issues.dlang.org/show_bug.cgi?id=10191 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #1 from bb.t...@gmx.com --- 2.069 ok --
[Issue 13608] std.range range interfaces hide @safe-ness
https://issues.dlang.org/show_bug.cgi?id=13608 Brad Robertschanged: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from Brad Roberts --- That unittest, now in std/algorithm/iteration.d, isn't marked pure yet. Looking at std.range.interfaces, only one test is marked @pure. For this to be closed, unit tests are needed. --
[Issue 6663] std.stdio conflicts with core.stdc.stdio
https://issues.dlang.org/show_bug.cgi?id=6663 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |INVALID --- Comment #6 from bb.t...@gmx.com --- invalid, see pantaleev comment. --
[Issue 11572] eager apply for ranges
https://issues.dlang.org/show_bug.cgi?id=11572 bb.t...@gmx.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #5 from bb.t...@gmx.com --- solved since each() implemented https://github.com/D-Programming-Language/phobos/pull/2024 --
[Issue 15366] Enum typed as bool behaves as bool even when cast
https://issues.dlang.org/show_bug.cgi?id=15366 Kenji Harachanged: What|Removed |Added Keywords||pull --- Comment #3 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/5279 --
[Issue 13654] @nogc std.range.enumerate
https://issues.dlang.org/show_bug.cgi?id=13654 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --
[Issue 15366] Enum typed as bool behaves as bool even when cast
https://issues.dlang.org/show_bug.cgi?id=15366 --- 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/67a21a9ec222e63ad5bab445662de9114878bc90 fix Issue 15366 - Enum typed as bool behaves as bool even when cast >From a CastExp 'a && b', its `semantic` returns an `AndAndExp` with the 'Enum' type. But if its `semantic` will be called once more, it will repaint its `type` to 'bool'. Same problem exists in `OrOrExp`. https://github.com/D-Programming-Language/dmd/commit/913ffbe000e99e3a2aa6caaea9994a103503d6ac Merge pull request #5279 from 9rnsr/fix15366 Issue 15366 - Enum typed as bool behaves as bool even when cast --
[Issue 3862] std.file.copy does not have the same behavior as cp
https://issues.dlang.org/show_bug.cgi?id=3862 --- Comment #12 from Vladimir Panteleev--- (In reply to Jonathan M Davis from comment #11) > @Vladimir Well, clearly you and I have very different expectations when > copying files. You haven't addressed any of the arguments I brought up. > So, if we're not going to fix std.file.copy to work like cp, and I > want a usable copy function, I'm clearly going to have to find the time to > write one myself and use that, and then I'll avoid std.file.copy like the > plague. In that case, I'll have to keep in mind to avoid any code you write like a plague ;) Because as I explained, in most situations using such a function is just wrong, and will result in buggy programs that crash in strange places if something doesn't go according to its plan. --
[Issue 12624] [REG 2.064] Internal error: backend\cgobj.c 2313 with Rebindable!(immutable TimeZone) in std.datetime
https://issues.dlang.org/show_bug.cgi?id=12624 Vladimir Panteleevchanged: What|Removed |Added CC||thecybersha...@gmail.com Summary|Internal error: |[REG 2.064] Internal error: |backend\cgobj.c 2313 with |backend\cgobj.c 2313 with |Rebindable!(immutable |Rebindable!(immutable |TimeZone) in std.datetime |TimeZone) in std.datetime Severity|blocker |regression --- Comment #6 from Vladimir Panteleev --- This is a regression. Introduced in https://github.com/D-Programming-Language/dmd/pull/2369 --
[Issue 15369] [REG master] id.d(369): Error: Outside Unicode code space
https://issues.dlang.org/show_bug.cgi?id=15369 Kenji Harachanged: What|Removed |Added Keywords||pull --- Comment #3 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/5280 --
[Issue 3862] std.file.copy does not have the same behavior as cp
https://issues.dlang.org/show_bug.cgi?id=3862 --- Comment #11 from Jonathan M Davis--- @Vladimir Well, clearly you and I have very different expectations when copying files. What I expect and what is pretty much exactly what cp does. e.g. with cp, I always use directory for the target and never provide a file name unless I'm renaming the file. And I screw it up every time that I use std.file.copy. I've just never gotten around to fixing it like I should have. So, if we're not going to fix std.file.copy to work like cp, and I want a usable copy function, I'm clearly going to have to find the time to write one myself and use that, and then I'll avoid std.file.copy like the plague. > 6. Do you know any programming languages whose copy function from their > standard library behaves like cp in this regard? D is the only language that I use with any regularity that even declares a copy function. So, my primary experience with copying files is cp, and cp's behavior is what I expect. I find std.file.copy's behavior to be very unfriendly in comparison. --
[Issue 3862] std.file.copy does not have the same behavior as cp
https://issues.dlang.org/show_bug.cgi?id=3862 --- Comment #14 from Jonathan M Davis--- (In reply to Vladimir Panteleev from comment #12) > (In reply to Jonathan M Davis from comment #11) > > @Vladimir Well, clearly you and I have very different expectations when > > copying files. > > You haven't addressed any of the arguments I brought up. I can see some corner cases where your concerns would be a problem, but in general, cp does exactly what I want, and having to do a bunch of additional checks is just annoying. And while I can definitely believe that there are programs where race conditions would be a concern or where it could be problematic to assume that the target is a directory, I've never personally written or worked on a program where that was a concern. (In reply to Vladimir Panteleev from comment #13) > I just looked at Python, and it provides both variants. We could introduce > "copyTo" which works in the same way, and perhaps also require that the path > ends with a directory separator for the "copy inside directory" behavior to > activate. Requiring a terminating directory separator would be annoying, but having separate functions where one requires that the target be a file and the other is more liberal does make sense. --
[Issue 12507] SysTime.init.toString should not segfault
https://issues.dlang.org/show_bug.cgi?id=12507 --- Comment #6 from Jonathan M Davis--- (In reply to Alaksiej Stankievič from comment #5) > What is currently status of this? > > I have hit this just now, and it consumes 1 hour of investigation. As the "Depends on" field indicates, it's blocked by issue# 12624. Attempting to provide a default TimeZone to SysTime won't compile on Windows due to a bug in the compiler backend. --
[Issue 13301] Inline ASM documentation does not allow string literals
https://issues.dlang.org/show_bug.cgi?id=13301 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/34d6b17582002eb1f3178c77664e459b555d7c4b Issue 13301 - Inline ASM documentation does not allow string literals https://github.com/D-Programming-Language/dlang.org/commit/20b34f54aaeb876b545bac1d34b954db15f0a237 Merge pull request #860 from Hackerpilot/issue-13301 Issue 13301 - Inline ASM documentation does not allow string literals --
[Issue 3862] std.file.copy does not have the same behavior as cp
https://issues.dlang.org/show_bug.cgi?id=3862 --- Comment #13 from Vladimir Panteleev--- (In reply to Vladimir Panteleev from comment #12) > In that case, I'll have to keep in mind to avoid any code you write like a > plague ;) OK, sorry, that was over the top. (In reply to Jonathan M Davis from comment #11) > D is the only language that I use with any regularity that even declares a > copy function. So, my primary experience with copying files is cp, and cp's > behavior is what I expect. I find std.file.copy's behavior to be very > unfriendly in comparison. I just looked at Python, and it provides both variants. We could introduce "copyTo" which works in the same way, and perhaps also require that the path ends with a directory separator for the "copy inside directory" behavior to activate. --
[Issue 15370] New: Some way to manually allocate the closure for delegates to nested functions.
https://issues.dlang.org/show_bug.cgi?id=15370 Issue ID: 15370 Summary: Some way to manually allocate the closure for delegates to nested functions. Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: joeyemm...@yahoo.com There has been a strong push to move away from the GC, being able to allocate closures with out it would be another step in that direction. As far as I can tell there is no current way to manually allocate a closure. It would be great if there was a solution that could work with allocators to be able to manually allocate closures. Example: auto foo(int x) { int bar(){ return x; } return // implicitly allocates a closure with the gc // No way to manually allocate it currently } Maybe it could be something as simple as __traits(setClosureAllocator, Mallocator.instance); to set the allocator for the closure of the current function. Allocators then would need to handle the case of freeing the delegate closure as well. --
[Issue 15335] getSymbolsByUDA fails if type has private members
https://issues.dlang.org/show_bug.cgi?id=15335 bb.t...@gmx.com changed: What|Removed |Added Hardware|x86_64 |All OS|Linux |All --- Comment #3 from bb.t...@gmx.com --- I've looked at your PR on GH and obviously the first one is better since it just prevents the error. The accessibility is a more global problem. Every time someone will put a function related to traits in a module and use this function in another module the same error will pop up. A mixin template allows to inject the function related to traits in the module it's used. So far it's ok, let's say for a private usage, (actually there's --0-- mixin template in phobos so I doubt they'll ever accept some new functions based on this, even if it works). Maybe the real solution would be to make "__traits(getMember,...)", and more generally speaking all the traits verbs that might also block compilation because of this, able to return any member, regardless of the protection. Then it would be up to the user to respect or not the protection using an additional "__traits(getProtection,...)" to filter an item in the traits code. --
[Issue 15366] Enum typed as bool behaves as bool even when cast
https://issues.dlang.org/show_bug.cgi?id=15366 --- Comment #2 from Lionello Lunesu--- Adding an explicit "this." fixed the issue: enum Enum : bool { A, B }; struct I{ void func(Enum e); void func2(Enum a, Enum b) {this.func(cast(Enum)(a&));} } Something happens when the compiler adds the "this" in your behalf. The resolution changes. --
[Issue 10039] std.algorithm enhancements: min, max, clamp
https://issues.dlang.org/show_bug.cgi?id=10039 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --- Comment #12 from bb.t...@gmx.com --- min(), max() & clamp() are all in std.algorithm.comparison now. --
[Issue 15371] New: __traits(getMember) should bypass the protection
https://issues.dlang.org/show_bug.cgi?id=15371 Issue ID: 15371 Summary: __traits(getMember) should bypass the protection Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: bb.t...@gmx.com "__traits(getMember,...)" should always work, whatever is the member protection (as long as the symbol is a valid one). The current limitation is problematic because it prevents to write functions related to traits in a separate dedicated modules (e.g mylib.traits) Every time a "__traits(getMember,...)" has to be used the only solution to make it works with a private member is to write again and again the code (or to warp the function in a mixin template). Since there is also the traits verb "getProtection", it still would be possible to respect the protection or not. In case this wouldn't be clear, more concretly: == module mylib.traits; mixin template ScopedReachability() { bool isMemberReachableGood(T, string member)() if (is(T==class) || is(T==struct)) { return __traits(compiles, __traits(getMember, T, member)); } } bool isMemberReachableBad(T, string member)() if (is(T==class) || is(T==struct)) { return __traits(compiles, __traits(getMember, T, member)); } = module somemodule; class Foo { private: uint a,b,c; public: this() { foreach(member; __traits(allMembers, Foo)) static if (isMemberReachableBad!(Foo, member)) {/*a,b,c not detected*/} import mylib.traits; mixin ScopedReachability; // isMemberReachableGood is now a local func. static if (isMemberReachableGood!(Foo, member)) {/*a,b,c detected*/} } } = With a relaxed protection policy on the "getMember" verb, it would be possible to write reusable functions related to traits. Actually the problem prevents a lot of good template that would simplify the traits usage to be written. = see also: - https://issues.dlang.org/show_bug.cgi?id=15335 - http://forum.dlang.org/post/xrrptwihnvlxabswn...@forum.dlang.org --
[Issue 15371] __traits(getMember) should bypass the protection
https://issues.dlang.org/show_bug.cgi?id=15371 --- Comment #1 from bb.t...@gmx.com --- something like that: https://github.com/Blumerline/dmd/commit/53419e71b93b0870574d93cbb83ebb7ccbb5e325 or maybe change in the Scope struct the module that indicates where the template should be instantiated (since it function that contains traits code will always be a template). --
[Issue 11015] BitArray.opCom is invalid on 64 bit machines
https://issues.dlang.org/show_bug.cgi?id=11015 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |FIXED --
[Issue 4766] Function to load a whole HTML page
https://issues.dlang.org/show_bug.cgi?id=4766 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bb.t...@gmx.com Resolution|--- |WORKSFORME --