[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.
https://issues.dlang.org/show_bug.cgi?id=2043 --- Comment #39 from Artem Borisovskiy --- Sorry for off-topic, but this discussion brought back memories of the classic song by Frank C Mantra: It's a feature, not a bug, No one really gives a *cough*, So if you want it to be fixed, Go on and fork it, badam badam pap-pa, How hard can it be, badam badam pap-pa, Trust me, it's worth it, badam badam pap-pa, In 10 years you'll se! --
[Issue 18493] [betterC] Can't use aggregated type with postblit
https://issues.dlang.org/show_bug.cgi?id=18493 --- Comment #3 from Radu Racariu --- Declaring `C` as --- struct C { S s1; } --- makes the test case compile. --
[Issue 18419] make all Phobos unittests version(StdUnittest)
https://issues.dlang.org/show_bug.cgi?id=18419 Nathan S. changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Nathan S. --- Idea nixed, so issue should be closed. --
[Issue 18768] object.getArrayHash with custom toHash shouldn't just sum hashes of array elements
https://issues.dlang.org/show_bug.cgi?id=18768 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/druntime/pull/2166 --
[Issue 18767] __xtoHash memberwise hashing shouldn't just sum the member hashes
https://issues.dlang.org/show_bug.cgi?id=18767 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/druntime/pull/2166 --
[Issue 18768] New: object.getArrayHash with custom toHash shouldn't just sum hashes of array elements
https://issues.dlang.org/show_bug.cgi?id=18768 Issue ID: 18768 Summary: object.getArrayHash with custom toHash shouldn't just sum hashes of array elements Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com Currently: ``` if(!hasCustomToHash(element)) return hashOf(ptr[0 .. elementSize * count], 0); size_t hash = 0; foreach(size_t i; 0 .. count) hash += element.getHash(ptr + i * elementSize); return hash; ``` --
[Issue 18767] New: __xtoHash memberwise hashing shouldn't just sum the member hashes
https://issues.dlang.org/show_bug.cgi?id=18767 Issue ID: 18767 Summary: __xtoHash memberwise hashing shouldn't just sum the member hashes Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com Currently: ``` const(char)* code = "size_t h = 0;" ~ "foreach (i, T; typeof(p.tupleof))" ~ "h += typeid(T).getHash(cast(const void*)&p.tupleof[i]);" ~ "return h;"; ``` --
[Issue 18766] std.typecons.Tuple.toHash could be improved
https://issues.dlang.org/show_bug.cgi?id=18766 Nathan S. changed: What|Removed |Added Severity|minor |enhancement --
[Issue 18766] std.typecons.Tuple.toHash could be improved
https://issues.dlang.org/show_bug.cgi?id=18766 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/phobos/pull/6457 --
[Issue 18766] New: std.typecons.Tuple.toHash could be improved
https://issues.dlang.org/show_bug.cgi?id=18766 Issue ID: 18766 Summary: std.typecons.Tuple.toHash could be improved Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com Current std.typecons.Tuple has a custom `toHash` that is just the sum of the hashes of the tuple's fields. --
[Issue 18757] static invariant{} should either work or not be valid syntax
https://issues.dlang.org/show_bug.cgi?id=18757 Andrei Alexandrescu changed: What|Removed |Added CC||and...@erdani.com --- Comment #8 from Andrei Alexandrescu --- The problem is that static methods don't call the static invariant. --
[Issue 18757] static invariant{} should either work or not be valid syntax
https://issues.dlang.org/show_bug.cgi?id=18757 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Hardware|x86_64 |All OS|Linux |All --- Comment #7 from Walter Bright --- A `static invariant` does not have special semantics distinct from `invariant` other than it does not have a `this` parameter. That fully explains the observed behavior. The `static` is not ignored: struct S { int i; static invariant { assert (i == 3); } // Error: need this for i of type int void foo() {} } void main() { S s; s.foo(); // invariant does get called } Whether that is desirable behavior or not is another matter entirely. Our general practice when confronted with these sorts of issues is to make it an error until we figure out what is the best approach, if there even is one, rather than inventing arbitrary behavior without much of any supporting rationale or use cases. --
[Issue 18757] static invariant{} should either work or not be valid syntax
https://issues.dlang.org/show_bug.cgi?id=18757 --- Comment #6 from FeepingCreature --- In my opinion, static this sets the precedent that static + class-level feature = module-level feature. --
[Issue 18757] static invariant{} should either work or not be valid syntax
https://issues.dlang.org/show_bug.cgi?id=18757 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #5 from Jonathan M Davis --- (In reply to FeepingCreature from comment #2) > In case 1, I maintain that this is a bug - the compiler should not > smile-and-nod while silently ignoring syntax that hints at a semantic that > does not apply. The reality of the matter is that the compiler ignores attributes like statict all over the place (e.g. static on most things at module scope is allowed and ignored, and you can do something like put @safe on a member variable without complaint from the compiler). If anything, it's extremely typical for the compiler to ignore attributes that don't apply rather than to treat them as an error. In some ways, this can be annoying, but it does help avoid problems in generic code. So, whether an error should be given in this particular case and not others is up for debate, but it's par for the course around here. (In reply to RazvanN from comment #4) > What about object that have static fields? If you have a static function > which modify static fields? I would argue that an invariant might want to > check whether a static function has modified the state of the object. We could certainly add a feature like that, but it's certainly not what invariant was designed for. Its purpose was specifically to verify the state of an object, and arguably, the static fields of an object aren't any different from those at module-sope except for the fact that they're scoped to be inside a struct or class. And as such, having an invariant for them would be pretty weird and is of pretty debatable value. If we went down that route, the question would become why we don't have module-level invariants. --
[Issue 18719] Doubly-called constructor against member when using forwarding constructors
https://issues.dlang.org/show_bug.cgi?id=18719 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18719] Doubly-called constructor against member when using forwarding constructors
https://issues.dlang.org/show_bug.cgi?id=18719 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/cbb49cb2591bd5aa3e5f9e0b8a4350cb04ec1206 Fix Issue 18719 - Doubly-called constructor against member when using forwarding constructors https://github.com/dlang/dmd/commit/ebecaf95ec84018c36cd1c388c4d9102c23622f7 Merge pull request #8167 from RazvanN7/Issue_18719 Fix Issue 18719 - Doubly-called constructor against member when using forwarding constructors merged-on-behalf-of: Andrei Alexandrescu --
[Issue 18762] DMD should use a unique path/filename for __stdin.o
https://issues.dlang.org/show_bug.cgi?id=18762 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/fdc6353140f059c25218a4d057eb7ebe20d69ef2 Fix Issue 18762 - DMD should use a unique path/filename for __stdin.o https://github.com/dlang/dmd/commit/bfb89f5099f4607d2b56a0508b3bbc6cec800de3 Merge pull request #8174 from CyberShadow/pull-20180416-133742 Fix Issue 18762 - DMD should use a unique path/filename for __stdin.o merged-on-behalf-of: Andrei Alexandrescu --
[Issue 18762] DMD should use a unique path/filename for __stdin.o
https://issues.dlang.org/show_bug.cgi?id=18762 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18757] static invariant{} should either work or not be valid syntax
https://issues.dlang.org/show_bug.cgi?id=18757 --- Comment #4 from RazvanN --- (In reply to uplink.coder from comment #3) > Well invariants cannot apply to static methods since they are only concerned > about the object's state. > which by definition cannot be directly touched in static functions. > that's why it's not called. > > I don't see that there is a basis to issue a warning. What about object that have static fields? If you have a static function which modify static fields? I would argue that an invariant might want to check whether a static function has modified the state of the object. --
[Issue 18757] static invariant{} should either work or not be valid syntax
https://issues.dlang.org/show_bug.cgi?id=18757 uplink.co...@googlemail.com changed: What|Removed |Added CC||uplink.co...@googlemail.com --- Comment #3 from uplink.co...@googlemail.com --- Well invariants cannot apply to static methods since they are only concerned about the object's state. which by definition cannot be directly touched in static functions. that's why it's not called. I don't see that there is a basis to issue a warning. --
[Issue 18757] static invariant{} should either work or not be valid syntax
https://issues.dlang.org/show_bug.cgi?id=18757 --- Comment #2 from FeepingCreature --- In case 1, I maintain that this is a bug - the compiler should not smile-and-nod while silently ignoring syntax that hints at a semantic that does not apply. --
[Issue 18762] DMD should use a unique path/filename for __stdin.o
https://issues.dlang.org/show_bug.cgi?id=18762 Vladimir Panteleev changed: What|Removed |Added Keywords||pull --- Comment #2 from Vladimir Panteleev --- https://github.com/dlang/dmd/pull/8174 --
[Issue 18757] static invariant{} should either work or not be valid syntax
https://issues.dlang.org/show_bug.cgi?id=18757 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- (In reply to FeepingCreature from comment #0) > Right now, you can define a struct to have a static invariant: > > struct S { > static invariant { assert(false); } > static void foo() { } > } > > But the invariant will not be checked when calling foo. > > Either this should work, or "static invariant {}" should be a syntax error. Placing static in front of an invariant has no effect on the invariant. The problem with the above code is that the method foo is marked as static: struct S { invariant { (assert (false); } static void foo() {} } void main() { S s; s.foo(); \\ invariant does not get called } while : struct S { static invariant { (assert (false); } void foo() {} } void main() { S s; s.foo(); \\ invariant does get called } So we can conclude that invariants are not called for static functions. The spec does not mention anything about this so there are 2 possibilities : 1. Invariants were designed only for struct/class instances (in which case the bug report will be closed with a spec update) 2. Invariants should also be called when static methods are called (in which case this should be fixed) --
[Issue 18736] constructor calls allowed after case labels
https://issues.dlang.org/show_bug.cgi?id=18736 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/15f525620895727147cf12e33596ae1a2d3ffa45 fix Issue 18736 - constructor calls allowed after case labels https://github.com/dlang/dmd/commit/49268c71adbc6631013d32c70152fd665d70760c Merge pull request #8143 from WalterBright/fix18736 fix Issue 18736 - constructor calls allowed after case labels --
[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.
https://issues.dlang.org/show_bug.cgi?id=18472 --- Comment #10 from Mike Franklin --- PR 8173 seems to take care of the case... module betterc; enum b = typeid(size_t) is typeid(uint) ... but still fails for ... import std.format; import std.stdio; void main() { enum s = "%1$s,%2$s".format("foo","bar"); writeln(s); } ... with the same TypeInfo error. However, if I comment out the TypeInfo check altogether, the `format` test case fails with... phobos/std/range/primitives.d(405): Error: static assert: "Cannot put a const(char)[] into a Appender!string." phobos/std/format.d(1184):instantiated from here: put!(Appender!string, const(char)[]) /phobos/std/format.d(473):instantiated from here: writeUpToNextSpec!(Appender!string) phobos/std/format.d(6168):instantiated from here: formattedWrite!(Appender!string, char, string, string) main.d(5):instantiated from here: format!(char, string, string) I'm wondering if there was another change to Phobos around the same time frame was the TypeInfo change that prevents the `format` expression from evaluating at compile-time. --
[Issue 18756] Escaping address of temporary struct field
https://issues.dlang.org/show_bug.cgi?id=18756 --- Comment #4 from Jonathan M Davis --- (In reply to anonymous4 from comment #3) > (In reply to Jonathan M Davis from comment #2) > > because it's always a bug. > It's correct when the result is passed to a function parameter. How so? --
[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.
https://issues.dlang.org/show_bug.cgi?id=18472 Mike Franklin changed: What|Removed |Added Keywords||pull --- Comment #9 from Mike Franklin --- Working on a fix at https://github.com/dlang/dmd/pull/8173 --
[Issue 18756] Escaping address of temporary struct field
https://issues.dlang.org/show_bug.cgi?id=18756 anonymous4 changed: What|Removed |Added Hardware|x86 |All OS|Windows |All --- Comment #3 from anonymous4 --- (In reply to Jonathan M Davis from comment #2) > because it's always a bug. It's correct when the result is passed to a function parameter. --
[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.
https://issues.dlang.org/show_bug.cgi?id=18472 --- Comment #8 from Mike Franklin --- (In reply to Rainer Schuetze from comment #7) > I think the main issue is that the compiler does not distinguish between > information needed at compile time and what's necessary inside the object > file. Ok, I understand now: `enum b = typeid(size_t) is typeid(uint);` should be evaluated at compile time, and I the -betterC limitations should only apply at runtime. --