[Issue 17141] CommonType!(dchar, char) returns uint
https://issues.dlang.org/show_bug.cgi?id=17141 Jack Stoufferchanged: What|Removed |Added Blocks||17358 --
[Issue 17141] CommonType!(dchar, char) returns uint
https://issues.dlang.org/show_bug.cgi?id=17141 Jack Stoufferchanged: What|Removed |Added Severity|major |critical --- Comment #7 from Jack Stouffer --- Raising this to critical because this is actually a bug in DMD's type inference and not a Phobos bug. --
[Issue 17141] CommonType!(dchar, char) returns uint
https://issues.dlang.org/show_bug.cgi?id=17141 --- Comment #5 from hst...@quickfur.ath.cx --- Hmph. Looks like the problem is that the very first thing typeMerge() does is to do integer promotion on the incoming types. Thus, right from the start, we've already lost the original character types. The only reason this hasn't shown up earlier is because when the two types are equal, typeMerge() is not called. So we're essentially only saved "by accident". Oddly enough, there is an `if (op != TOKquestion || ...)`, which *seems* to suggest that the intent of the code is *not* to do integer promotions if ?: is involved. However, the second clause of the if condition, `t1b.ty != t2b.ty`, appears to be always true, so the check for ?: would appear to be always irrelevant. It would seem that && was intended here rather than ||, but I've to look more carefully to make sure this isn't going to cause massive code breakage... --
[Issue 17141] CommonType!(dchar, char) returns uint
https://issues.dlang.org/show_bug.cgi?id=17141 --- Comment #4 from hst...@quickfur.ath.cx --- Looks like this is implemented in the hairball function typeMerge() in src/ddmd/dcast.d. I'll try to trace through and see if I can find an obvious problem, but I'm not sure if I'll be able to. --
[Issue 17141] CommonType!(dchar, char) returns uint
https://issues.dlang.org/show_bug.cgi?id=17141 hst...@quickfur.ath.cx changed: What|Removed |Added Component|phobos |dmd --
[Issue 17141] CommonType!(dchar, char) returns uint
https://issues.dlang.org/show_bug.cgi?id=17141 --- Comment #3 from hst...@quickfur.ath.cx --- Unfortunately, it looks like CommonType is implemented using the ?: ternary operator, meaning that it's the *compiler* that's producing these crazy results. --
[Issue 17141] CommonType!(dchar, char) returns uint
https://issues.dlang.org/show_bug.cgi?id=17141 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #2 from hst...@quickfur.ath.cx --- It's not just CommonType!(dchar, char); it's a whole slew of cases that are incorrectly handled: void main() { import std.range; struct CharRange(C) { C ch = 'a'; @property C front() { return ch; } @property bool empty() { return ch == C.init; } void popFront() { ch = C.init; } } CharRange!char charRange; CharRange!wchar wcharRange; CharRange!dchar dcharRange; pragma(msg, "char + char: ", ElementType!(typeof(chain(charRange, charRange; pragma(msg, "char + wchar: ", ElementType!(typeof(chain(charRange, wcharRange; pragma(msg, "wchar + char: ", ElementType!(typeof(chain(wcharRange, charRange; pragma(msg, "char + dchar: ", ElementType!(typeof(chain(charRange, dcharRange; pragma(msg, "dchar + char: ", ElementType!(typeof(chain(dcharRange, charRange; pragma(msg, "wchar + wchar: ", ElementType!(typeof(chain(wcharRange, wcharRange; pragma(msg, "wchar + dchar: ", ElementType!(typeof(chain(wcharRange, dcharRange; pragma(msg, "dchar + wchar: ", ElementType!(typeof(chain(dcharRange, wcharRange; pragma(msg, "dchar + dchar: ", ElementType!(typeof(chain(dcharRange, dcharRange; } Output: char + char: char char + wchar: int wchar + char: int char + dchar: uint dchar + char: uint wchar + wchar: wchar wchar + dchar: uint dchar + wchar: uint dchar + dchar: dchar Seems like the only time the correct common type is deduced, as far as character types are concerned, is when both are types are the same. All the other cases are worthy of a WAT?. --
[Issue 17141] CommonType!(dchar, char) returns uint
https://issues.dlang.org/show_bug.cgi?id=17141 Jack Stoufferchanged: What|Removed |Added Severity|normal |major --- Comment #1 from Jack Stouffer --- Raising the priority of this because chain is really gimped by this bug. Every call to chain with character ranges requires an extra call to map to cast the results for it to work correctly. --