https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #12 from yebblies <[email protected]> --- (In reply to Kenji Hara from comment #9) > (In reply to yebblies from comment #6) > > Then, because it knows that 4 can fit in a char, it allows it to become > > this: > > > > enum alice = "{ int t_"~cast(char)4~" = 42; }"; > > I think the problem is here. The constfold will change the value type uint > to char unintentionally. I think the bare integer literal `4` and the > expanded value `4` from a manifest constant `ln` should be handled > differently. > > - A bare integer literal `4` should work as a polysemous expression, so > implicit casting it to char is possible because 4 can fit the value range of > char type. > > - An expanded integer `4` typed uint should work as an "interger", at least. > Therefore converting it to char implicitly is unnatural behavior. > (With the same logic, `ln` should not be implicitly convertible to bool.) > This is sort of the whole point of VRP, and I don't see how you can make it work without crippling it. The implicit conversion from int (etc) to char is useful and intentional. Even if you wanted to make 'explicitly' typed declarations differently, these would have to be treated the same: enum c = 'a' + 1; // no explicit type, but will be inferred as int enum int d = 'a' + 1; // explicitly typed as int enum x = "xxx" ~ c ~ d; --
