[Issue 12777] New: const/immutable member function violating its const-ness - confusing error message
https://issues.dlang.org/show_bug.cgi?id=12777
Issue ID: 12777
Summary: const/immutable member function violating its
const-ness - confusing error message
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: ga...@mail.ru
If a const/immutable member function tries to modify the contents of its struct
or class, the error message is present (ok) but confusing (not ok).
Example:
-
struct S {
int v;
void fun () const {v++;}
void gun () immutable {v++;}
}
class C {
int v;
void fun () const {v++;}
void gun () immutable {v++;}
}
void main () {}
-
Error message:
-
const_member.d(3): Error: can only initialize const member v inside constructor
const_member.d(4): Error: can only initialize const member v inside constructor
const_member.d(8): Error: can only initialize const member v inside constructor
const_member.d(9): Error: can only initialize const member v inside constructor
-
The error is indeed there: none of these functions are allowed to alter v.
However, the error message text is confusing.
First, member v is not constant - the method is. So, no apparent reason to
mention the constructor.
Second, altering a variable is not necessarily initialization (v++;).
--
[Issue 12777] const/immutable member function violating its const-ness - confusing error message
https://issues.dlang.org/show_bug.cgi?id=12777 --- Comment #1 from Ivan Kazmenko ga...@mail.ru --- Created attachment 1357 -- https://issues.dlang.org/attachment.cgi?id=1357action=edit source code of the demonstrating example --
[Issue 12777] const/immutable member function violating its const-ness - confusing error message
https://issues.dlang.org/show_bug.cgi?id=12777
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
(In reply to Ivan Kazmenko from comment #0)
First, member v is not constant - the method is.
No, it's not the 'method', it's the 'this' reference which is constant. And
const is transitive in D, which means all fields are constant. The above is
equivalent to:
-
struct S {
const(int) v; // as seen from 'fun'
void fun () const {v++;}
}
struct S {
immutable(int) v; // as seen from 'fun'
void fun () immutable {v++;}
}
-
However I do agree the diagnostic could be improved a bit.
--
[Issue 12777] const/immutable member function violating its const-ness - confusing error message
https://issues.dlang.org/show_bug.cgi?id=12777 bearophile_h...@eml.cc changed: What|Removed |Added Keywords||diagnostic CC||bearophile_h...@eml.cc --- Comment #3 from bearophile_h...@eml.cc --- What error message do you suggest? Perhaps something like this? test.d(3): Error: const methods (like 'S.fun') cannot modify instance members (like 'S.v'), only constructors can initialize them test.d(4): Error: immutable methods (like 'S.gun') cannot modify instance members (like 'S.v'), only constructors can initialize them --
[Issue 6400] opDispatch with WithStatement
https://issues.dlang.org/show_bug.cgi?id=6400 Vlad Levenfeld vlevenf...@gmail.com changed: What|Removed |Added CC||vlevenf...@gmail.com --
[Issue 9808] with statement does not work with opDispatch
https://issues.dlang.org/show_bug.cgi?id=9808 Vlad Levenfeld vlevenf...@gmail.com changed: What|Removed |Added CC||vlevenf...@gmail.com --
[Issue 12778] New: Aliasing opBinaryRight to opBinary works only in certain cases
https://issues.dlang.org/show_bug.cgi?id=12778
Issue ID: 12778
Summary: Aliasing opBinaryRight to opBinary works only in
certain cases
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
I've discovered a feature today where I can simply alias opBinaryRight to
opBinary and it will work. However it stops working when 'const' is involved.
Observe:
-
struct Vec2
{
Vec2 opBinary(string op)(Vec2 b) const
if (op == + || op == - || op == *)
{
mixin(return Vec2(this.x ~ op ~ b.x, this.y ~ op ~ b.y););
}
Vec2 opBinary(string op)(float s) const
if (op == + || op == - || op == *)
{
mixin(return Vec2(s ~ op ~ this.x, s ~ op ~ this.y););
}
alias opBinaryRight = opBinary;
float x = 0, y = 0;
}
void main()
{
Vec2 vec;
auto v1 = vec + 1; // ok
auto v2 = 1 + vec; // ok, opBinaryRight alias works!
struct S
{
void test1()
{
Vec2 v = v1 - v2; // ok
}
void test2() const
{
Vec2 v = v1 - v2; // L37: error
}
Vec2 v1, v2;
}
}
-
test.d(37): Error: overloads const pure nothrow @nogc @safe Vec2(Vec2 b) and
const (Vec2 b) both match argument list for opBinary
I don't know if supporting this kind of aliasing was a feature by design or by
mistake. It's definitely nice to have it, but it fails in 'test2'. It should
either be fully supported (rejects-valid) or fully rejected (accepts-invalid).
--
[Issue 12777] const/immutable member function violating its const-ness - confusing error message
https://issues.dlang.org/show_bug.cgi?id=12777
--- Comment #4 from Ivan Kazmenko ga...@mail.ru ---
(In reply to bearophile_hugs from comment #3)
What error message do you suggest? Perhaps something like this?
test.d(3): Error: const methods (like 'S.fun') cannot modify instance
members (like 'S.v'), only constructors can initialize them
test.d(4): Error: immutable methods (like 'S.gun') cannot modify instance
members (like 'S.v'), only constructors can initialize them
The part about constructors is formally false: not only constructors can
initialize a non-const instance member.
Here's a C++ variant and the respective errors for inspiration:
-
struct S {
int v;
void fun () const {v++;}
};
class C {
int v;
void fun () const {v++;}
};
int main (void) {}
-
GCC - g++ errors:
-
const_member.cpp: In member function 'void S::fun() const':
const_member.cpp:3:25: error: increment of member 'S::v' in read-only object
void fun () const {v++;} ^
const_member.cpp: In member function 'void C::fun() const':
const_member.cpp:7:25: error: increment of member 'C::v' in read-only object
void fun () const {v++;}
^
-
CLang - clang++ errors:
-
const_member.cpp:3:25: error: read-only variable is not assignable
void fun () const {v++;}
~^
const_member.cpp:7:25: error: read-only variable is not assignable
void fun () const {v++;}
~^
-
Visual Studio 12 - cl.exe errors:
-
const_member.cpp(3) : error C3490: 'v' cannot be modified because it is being
accessed through a const object
const_member.cpp(7) : error C3490: 'v' cannot be modified because it is being
accessed through a const object
-
I'd say Visual Studio's message is the most readable.
--
[Issue 12777] const/immutable member function violating its const-ness - confusing error message
https://issues.dlang.org/show_bug.cgi?id=12777
--- Comment #5 from Ivan Kazmenko ga...@mail.ru ---
(In reply to Andrej Mitrovic from comment #2)
(In reply to Ivan Kazmenko from comment #0)
First, member v is not constant - the method is.
No, it's not the 'method', it's the 'this' reference which is constant. And
const is transitive in D, which means all fields are constant. The above is
equivalent to:
-
struct S {
const(int) v; // as seen from 'fun'
void fun () const {v++;}
}
struct S {
immutable(int) v; // as seen from 'fun'
void fun () immutable {v++;}
}
-
However I do agree the diagnostic could be improved a bit.
Thank you for the explanation! I see now how it makes sense from the
compiler's point of view. For the programmer however, it is convenient (and
safe, right?) to reason as method is constant means it can not modify its
object, and reading the current message somewhat breaks that model of
thinking.
--
[Issue 4474] Better stdin.byLine()
https://issues.dlang.org/show_bug.cgi?id=4474 bearophile_h...@eml.cc changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #7 from bearophile_h...@eml.cc --- Reopened. byLine can't be renamed byLineMutable, so byLine is the noncopying one and byLineCopy is the copying one. So here the default short functions is unfortunately the less safe one, against the D Zen: https://github.com/D-Programming-Language/phobos/pull/2077 --
[Issue 12779] New: [REG2.066a] -inline makes wrong code under some conditions
https://issues.dlang.org/show_bug.cgi?id=12779
Issue ID: 12779
Summary: [REG2.066a] -inline makes wrong code under some
conditions
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Keywords: wrong-code
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: j...@red.email.ne.jp
This issue is triggered by:
https://github.com/D-Programming-Language/dmd/pull/2561
I have struggled to reduce it though it is rather complicated.
SOURCE FILES:
*lib.d -
module lib;
void test( string data) {
auto ret = new Foo();
ret.data = data;
assert(ret.data.length 1_000_000); // OK!
ret.check(); // NG
}
class Foo {
// Removing this or changing order of these members
// affects the runtime behavior ...
version (defined) {
int[int] unusedAA;
}
string data;
void check() {
assert(data.length 1_000_000); // NG!
}
}
*main.d -
import lib;
void main()
{
string data = text;
test( data);
}
COMMANDS(compile and run):
dmd.exe -lib -version=defined lib.d
dmd.exe -g -inline inlinebug.d lib.lib
inlinebug.exe
OUTPUT:
core.exception.AssertError@lib.d(20): Assertion failure
0x00402487 in _d_assert
0x004020DB in void lib.Foo.check()
0x0040206C in _Dmain
--
[Issue 12779] [REG2.066a] -inline makes wrong code under some conditions
https://issues.dlang.org/show_bug.cgi?id=12779 --- Comment #1 from j...@red.email.ne.jp --- Whether inlining the function 'test' or not makes difference. However, other conditions affect strange. --
[Issue 6889] finally mentioned in a compilation error, instead of scope(exit) or scope(success)
https://issues.dlang.org/show_bug.cgi?id=6889 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/3564 --
[Issue 2456] cannot put catch statement inside finally block, missing line number
https://issues.dlang.org/show_bug.cgi?id=2456 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #4 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3564 --
[Issue 12780] New: Multiplying integer vector by scalar double fails
https://issues.dlang.org/show_bug.cgi?id=12780
Issue ID: 12780
Summary: Multiplying integer vector by scalar double fails
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: sfrijt...@gmail.com
void main() {
int ifoo = 2;
int[3] ibar = 1;
double dfoo = 2.0;
double[3] dbar = 1.0;
dfoo = ifoo * dfoo; // Scalar int * scalar double -- OK
dfoo = dfoo * dfoo; // Scalar double * scalar double -- OK
dbar = dfoo * dbar[];// Scalar double * array of double --
OK
ibar = ifoo * ibar[];// Scalar int * array of int -- OK
dbar = ifoo * dbar[];// Scalar int * array of double -- OK
dbar = dfoo * ibar[];// Scalar double * array of int -- FAIL
}
I would have expected the last case to work as well, but I get
testarr.d(13): Error: incompatible types for ((dfoo) * (ibar[])):
'double' and 'int[]'
Discussion at
http://forum.dlang.org/thread/uxuhzwkefamcnqsbw...@forum.dlang.org suggests
that this an unnecessary restriction and could be lifted.
--
[Issue 12739] Foreach delegate to opApply does not have infered nothrow
https://issues.dlang.org/show_bug.cgi?id=12739 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3565 --
[Issue 12774] REG(2.066) ICE(optimize.c) Newing struct containing union causes segfault
https://issues.dlang.org/show_bug.cgi?id=12774 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com --- (In reply to Vladimir Panteleev from comment #1) Introduced in https://github.com/D-Programming-Language/dmd/pull/3536 Correction: Introduced in https://github.com/D-Programming-Language/dmd/pull/3522 Compiler fix: https://github.com/D-Programming-Language/dmd/pull/3566 --
[Issue 12774] REG(2.066) ICE(optimize.c) Newing struct containing union causes segfault
https://issues.dlang.org/show_bug.cgi?id=12774 --- 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/b5c24575a528faf869f61352618d12a805d5c4ca fix Issue 12774 - ICE(optimize.c) Newing struct containing union causes segfault https://github.com/D-Programming-Language/dmd/commit/c6f3e95275ac79bb9ceecbe6d2277f632297182a Merge pull request #3566 from 9rnsr/fix12774 [REG2.066a] Issue 12774 - ICE(optimize.c) Newing struct containing union causes segfault --
[Issue 9570] Wrong foreach index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=9570 Lionello Lunesu lio+bugzi...@lunesu.com changed: What|Removed |Added Keywords||pull CC||lio+bugzi...@lunesu.com --- Comment #3 from Lionello Lunesu lio+bugzi...@lunesu.com --- https://github.com/D-Programming-Language/dmd/pull/3567 --
[Issue 9570] Wrong foreach index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=9570
--- Comment #4 from bearophile_h...@eml.cc ---
(In reply to Lionello Lunesu from comment #3)
https://github.com/D-Programming-Language/dmd/pull/3567
Is this supported?
void main() {
ubyte[256] data;
foreach (ubyte i, ref x; data)
x = i;
}
--
[Issue 9570] Wrong foreach index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=9570
--- Comment #5 from Lionello Lunesu lio+bugzi...@lunesu.com ---
(In reply to bearophile_hugs from comment #4)
(In reply to Lionello Lunesu from comment #3)
https://github.com/D-Programming-Language/dmd/pull/3567
Is this supported?
void main() {
ubyte[256] data;
foreach (ubyte i, ref x; data)
x = i;
}
No, the key must be declared const or immutable. Otherwise we need flow
analysis to ensure the key doesn't get mutated in the scope.
--
[Issue 9570] Wrong foreach index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=9570
--- Comment #6 from bearophile_h...@eml.cc ---
(In reply to Lionello Lunesu from comment #5)
No, the key must be declared const or immutable. Otherwise we need flow
analysis to ensure the key doesn't get mutated in the scope.
I don't understand what's the problem. What kind of bad things do happen if the
key gets mutated in the scope?
void main() {
ubyte[256] data;
foreach (ubyte i, ref x; data) {
x = i;
i++; // overflow here
}
}
--
[Issue 12781] New: process.d: Executable file not found is supposed to show executable name but fails
https://issues.dlang.org/show_bug.cgi?id=12781
Issue ID: 12781
Summary: process.d: Executable file not found is supposed to
show executable name but fails
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: van.de.bug...@gmail.com
Look at file phobos/std/process.d line ~360, it is the very beginning of
function spawnProcessImpl:
const(char)[] name = args[0];
if (any!isDirSeparator(name))
{
if (!isExecutable(name))
throw new ProcessException(text(Not an executable
file: , name));
}
else
{
name = searchPathFor(name);
if (name is null)
throw new ProcessException(text(Executable file not
found: , name));
}
Look at the else clause. If function searchPathFor failed, we
are throwing an error Executable file not found: , which is
supposed to include name of executable file. But name at this
moment is null... :-(
--
[Issue 12781] process.d: Executable file not found is supposed to show executable name but fails
https://issues.dlang.org/show_bug.cgi?id=12781 van.de.bug...@gmail.com changed: What|Removed |Added Hardware|x86_64 |All Severity|enhancement |normal --
[Issue 9570] Wrong foreach index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=9570
--- Comment #7 from yebblies yebbl...@gmail.com ---
(In reply to bearophile_hugs from comment #6)
(In reply to Lionello Lunesu from comment #5)
No, the key must be declared const or immutable. Otherwise we need flow
analysis to ensure the key doesn't get mutated in the scope.
I don't understand what's the problem. What kind of bad things do happen if
the key gets mutated in the scope?
void main() {
ubyte[256] data;
foreach (ubyte i, ref x; data) {
x = i;
i++; // overflow here
}
}
If i is mutated before it's used, the range information from the foreach
aggregate might not be accurate. Your example is fine, but to tell it apart
from the bad ones requires flow analysis for non-trivial cases.
void main() {
ubyte[256] data;
foreach (ubyte i, ref x; data) {
i = 9;
x = i; // information lost
}
}
--
[Issue 9570] Wrong foreach index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=9570
--- Comment #8 from bearophile_h...@eml.cc ---
(In reply to yebblies from comment #7)
void main() {
ubyte[256] data;
foreach (ubyte i, ref x; data) {
i = 9;
x = i; // information lost
}
}
This code should give (as it currently gives):
temp.d(4,13): Error: cannot implicitly convert expression (9) of type int
to ubyte
Here i scan a ubyte range 0 .. 255, so tagging it as ubyte is OK. I think it's
irrelevant that later I try to overflow the contents of i.
Even this is OK for D, despite 'i' gets overflowed:
void main() {
ubyte[256] data;
foreach (ubyte i, ref x; data) {
i += 200;
i = 200;
x = i;
}
}
So I still don't see the problem.
--
[Issue 9570] Wrong foreach index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=9570 --- Comment #9 from yebblies yebbl...@gmail.com --- Oh right, I misread your example. That won't be fixed by this pull. --
[Issue 9570] Wrong foreach index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=9570 --- Comment #10 from Lionello Lunesu lio+bugzi...@lunesu.com --- I also misread. The problem here is that the internal iterator (the one named __key##, declared by the compiler) needs to be able to count to 256 inclusive (for the comparison the be false and terminate the for.) There's no reason why the internal iterator and the declared one are the same type (in fact, they need not be), but at the moment the compiler uses the declared type for both the declared iterator and the internal one. It's an unrelated fix. --
[Issue 9570] Wrong foreach index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=9570 --- Comment #11 from Lionello Lunesu lio+bugzi...@lunesu.com --- In fact, we should probably open a new bug for that case, since it's not the same. --
[Issue 6949] no warning or error if unsigned variable is compared to
https://issues.dlang.org/show_bug.cgi?id=6949 --- Comment #18 from Lionello Lunesu lio+bugzi...@lunesu.com --- *** Issue 8874 has been marked as a duplicate of this issue. *** --
[Issue 8874] Possible warning for always true/always false comparisons on unsigned values
https://issues.dlang.org/show_bug.cgi?id=8874 Lionello Lunesu lio+bugzi...@lunesu.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lio+bugzi...@lunesu.com Resolution|--- |DUPLICATE --- Comment #1 from Lionello Lunesu lio+bugzi...@lunesu.com --- *** This issue has been marked as a duplicate of issue 6949 *** --
[Issue 12782] New: Wrong foreach mutable index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=12782
Issue ID: 12782
Summary: Wrong foreach mutable index implicit conversion error
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
Apparently the bug fix of Issue 9570 is not able to handle this case, so this
is a new enhancement request. I think this code should be accepted:
void main() {
ubyte[256] data;
foreach (ubyte i, ref x; data) {
i += 200;
i = 200;
x = i;
}
}
With dmd 2.066alpha it gives:
temp.d(3,5): Error: index type 'ubyte' cannot cover index range 0..256
--
[Issue 9570] Wrong foreach index implicit conversion error
https://issues.dlang.org/show_bug.cgi?id=9570 --- Comment #12 from bearophile_h...@eml.cc --- (In reply to Lionello Lunesu from comment #11) In fact, we should probably open a new bug for that case, since it's not the same. OK, it's Issue 12782 --
[Issue 12783] New: Adding 'Third Party Libraries' link to the navigation sidebar
https://issues.dlang.org/show_bug.cgi?id=12783 Issue ID: 12783 Summary: Adding 'Third Party Libraries' link to the navigation sidebar Product: D Version: unspecified Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: marki...@umich.edu Andrei was talking about code.dlang.org not being particularly well known at DConf today. I had actually never heard of it prior to then. I think that this problem is one that is best solved by doing something quite simple: Adding a link in the sidebars to point to this wonderful collection. Expect a pull request within 5 minutes of submitting this bug. --
[Issue 12783] Adding 'Third Party Libraries' link to the navigation sidebar
https://issues.dlang.org/show_bug.cgi?id=12783 Mark Isaacson marki...@umich.edu changed: What|Removed |Added Keywords||pull --- Comment #1 from Mark Isaacson marki...@umich.edu --- Pull request: https://github.com/D-Programming-Language/dlang.org/pull/580 --
[Issue 6949] no warning or error if unsigned variable is compared to
https://issues.dlang.org/show_bug.cgi?id=6949 --- Comment #19 from bearophile_h...@eml.cc --- (In reply to Lionello Lunesu from comment #18) *** Issue 8874 has been marked as a duplicate of this issue. *** Issue 8874 shows an extensive example of why this warning is quite important. --
[Issue 12784] New: Add an in operator for std.json.JSONValue
https://issues.dlang.org/show_bug.cgi?id=12784 Issue ID: 12784 Summary: Add an in operator for std.json.JSONValue Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: marki...@umich.edu Currently the only way to check if a JSONValue (that is of type JSON_TYPE.OBJECT) contains a particular key/property is to wrap opIndex with a try catch block. This feels horribly clumsy. We should have an opBinaryRight in operator to allow checking without throwing. Expect a pull request with the fix by end of day. --
[Issue 12784] Add an in operator for std.json.JSONValue
https://issues.dlang.org/show_bug.cgi?id=12784 Mark Isaacson marki...@umich.edu changed: What|Removed |Added Keywords||pull --- Comment #1 from Mark Isaacson marki...@umich.edu --- Submitted pull request: https://github.com/D-Programming-Language/phobos/pull/2194 --
[Issue 12785] New: Optimize with switches some associative array usage idioms
https://issues.dlang.org/show_bug.cgi?id=12785
Issue ID: 12785
Summary: Optimize with switches some associative array usage
idioms
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
In D there are handy associative array literals, so D code contains idioms that
are more typical of dynamic languages as Python:
size_t foo(in char c) {
immutable size_t[char] indexer =
['D': 2, 'R': 5, 'C': 8, 'H': 9, 'W': 0];
return indexer[c];
}
size_t foo(in char c) {
return ['D': 2, 'R': 5, 'C': 8, 'H': 9, 'W': 0][c];
}
So I suggest to add to D front-end an optimization, that rewrites those usages
of associative arrays with a switch:
size_t foo(in char c) {
size_t value = size_t.max;
switch (c) {
case 'D': value = 2; break;
case 'R': value = 5; break;
case 'C': value = 8; break;
case 'H': value = 9; break;
case 'W': value = 0; break;
default: assert(false);
}
return value;
}
This should be faster, avoid GC activity, and produce simpler binaries.
--
[Issue 12784] Add an in operator for std.json.JSONValue
https://issues.dlang.org/show_bug.cgi?id=12784 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5a6b03a974ac6267060de278c76edeac0a01e6e6 Merge pull request #2194 from markisaa/jsonValueInOp Issue 12784: Added an in operator to std.json.JSONValue. Tested when const/non-const --
[Issue 12784] Add an in operator for std.json.JSONValue
https://issues.dlang.org/show_bug.cgi?id=12784 Mark Isaacson marki...@umich.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12760] Initializing an object that has this(Args) inout causes discards return value warning
https://issues.dlang.org/show_bug.cgi?id=12760 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #3 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3569 --
[Issue 12774] REG(2.066) ICE(optimize.c) Newing struct containing union causes segfault
https://issues.dlang.org/show_bug.cgi?id=12774 --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com --- Ah, my bad! I noticed my Digger cache got messed up today, sorry about that. --
[Issue 3743] Forward reference problem with static if statements
https://issues.dlang.org/show_bug.cgi?id=3743 Adam Wilson flybo...@gmail.com changed: What|Removed |Added CC||flybo...@gmail.com Version|D1 |D2 Severity|normal |major --
[Issue 9657] static if (is(typeof(method))) broken with final and template mixins
https://issues.dlang.org/show_bug.cgi?id=9657 Adam Wilson flybo...@gmail.com changed: What|Removed |Added CC||adam.chrapkow...@gmail.com, ||digitalmars-d-bugs@puremagi ||c.com, flybo...@gmail.com, ||nob...@puremagic.com --
[Issue 3743] Forward reference problem with static if statements
https://issues.dlang.org/show_bug.cgi?id=3743 Adam Wilson flybo...@gmail.com changed: What|Removed |Added CC||adam.chrapkow...@gmail.com, ||digitalmars-d-bugs@puremagi ||c.com, nob...@puremagic.com --
[Issue 3743] Forward reference problem with static if statements
https://issues.dlang.org/show_bug.cgi?id=3743
--- Comment #1 from Adam Wilson flybo...@gmail.com ---
Updating this bug. Note that this effects Aurora Graphics.
The following will produce an 'undefined identifier' error in struct
DWRITE_GLYPH_RUN on IDWriteFontFace
static if(DX110)
{
public struct DWRITE_GLYPH_RUN {
IDWriteFontFace fontFace; //Error: Undefined Identifier
//...
}
}
static if(DX111) { //...}
static if(DX112) { //...}
static if(DX110)
{
public interface IDWriteFontFace : IUnknown
{
HRESULT GetDesignGlyphMetrics(const(uint*) Indices, uint Count,
DWRITE_GLYPH_METRICS*
//...
}
}
static if(DX111) { //...}
static if(DX112) { //...}
--
