https://issues.dlang.org/show_bug.cgi?id=16390
Ketmar Dark changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
--
https://issues.dlang.org/show_bug.cgi?id=16394
Ketmar Dark changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
--
https://issues.dlang.org/show_bug.cgi?id=16397
Issue ID: 16397
Summary: test_runner in coverage mode doesn't match with
individual test (covers less)
Product: D
Version: D2
Hardware: x86_64
OS: Linux
https://issues.dlang.org/show_bug.cgi?id=15951
--- Comment #6 from Johan Engelen ---
Same issue: https://issues.dlang.org/show_bug.cgi?id=11331
--
https://issues.dlang.org/show_bug.cgi?id=16394
Ali Cehreli changed:
What|Removed |Added
Keywords||industry
CC|
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #21 from Steven Schveighoffer ---
(In reply to Eyal from comment #20)
> It could be nice to add a setInit method that sets a given buffer to the
> initial value, with no corner cases at all.
Agreed. I was thinking the same thing.
--
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #20 from Eyal ---
It could be nice to add a setInit method that sets a given buffer to the
initial value, with no corner cases at all.
--
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #16 from Steven Schveighoffer ---
(In reply to Eyal from comment #1)
> Prints out:
> [Int(1, 7FE7FED92000), Int(2, 7FE7FED92000)]
> [Int(3, null), Int(0, 73)]
>
> The second field being printed for Int seems like *yet another* bug.
The
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #19 from Steven Schveighoffer ---
(In reply to Eyal from comment #17)
> Yeah, I've since figured it out - but was surprised because it is
> inconsistent with code blocks like: x=>x+1 which is inferred to be a
> function, not a delegate.
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #18 from Steven Schveighoffer ---
druntime documentation PR: https://github.com/dlang/druntime/pull/1634
phobos initializeAll PR: https://github.com/dlang/phobos/pull/4736
--
https://issues.dlang.org/show_bug.cgi?id=16394
Steven Schveighoffer changed:
What|Removed |Added
Keywords||pull, spec
--
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #17 from Eyal ---
> The other field being printed is the context pointer, since your struct is
> nested in the unittest.
Yeah, I've since figured it out - but was surprised because it is inconsistent
with code blocks like: x=>x+1 which
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #15 from Steven Schveighoffer ---
I just disagree that the current behavior is a bug. Note that this wasn't
documented to begin with, and whoever documented it (probably me) didn't
realize the corner case behavior. This was never a code b
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #14 from ag0ae...@gmail.com ---
(In reply to Steven Schveighoffer from comment #12)
> 3) Changing the compiler potentially introduces new issues. Changing the
> docs does not.
(In reply to Steven Schveighoffer from comment #13)
> changing
https://issues.dlang.org/show_bug.cgi?id=14246
--- Comment #3 from Sobirari Muhomori ---
How does it affect safety?
--
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #13 from Steven Schveighoffer ---
changing the compiler when the existing code works JUST FINE as long as it's
properly understood and documented seems like a horrible idea to me.
It would be a different story if it was not possible to p
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #12 from Steven Schveighoffer ---
3) Changing the compiler potentially introduces new issues. Changing the docs
does not.
--
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #11 from ag0ae...@gmail.com ---
Alright, these are arguments for changing the documentation instead of the
implementation:
1) Changing the behavior would break existing code.
2) It's hard or impossible to fix in a satisfactory way. In par
https://issues.dlang.org/show_bug.cgi?id=16394
--- Comment #10 from Steven Schveighoffer ---
A compile time error isn't possible, as this is a virtual function. It would
have to be a runtime error, which I think is even worse.
Let's just fix the docs, any bugs that are in druntime/Phobos, and mo
https://issues.dlang.org/show_bug.cgi?id=16395
--- Comment #3 from greenify ---
> True in general, but not really an option for my code (I need a certain
> amount of runtime polymorphism).
I thought so :/
> Regardless of my example, which I solved with option 2, the question of this
> issue i
https://issues.dlang.org/show_bug.cgi?id=16395
Lodovico Giaretta changed:
What|Removed |Added
CC||lodov...@giaretart.net
--- Comment #2 fr
https://issues.dlang.org/show_bug.cgi?id=16396
Issue ID: 16396
Summary: Octal value 08 should result in error
Product: D
Version: D2
Hardware: Other
OS: Linux
Status: NEW
Severity: enhancement
Prio
https://issues.dlang.org/show_bug.cgi?id=16395
greenify changed:
What|Removed |Added
CC||greeen...@gmail.com
--- Comment #1 from greenify
https://issues.dlang.org/show_bug.cgi?id=16395
Issue ID: 16395
Summary: auto return on override
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: spec
Severity: enhancement
24 matches
Mail list logo
