https://issues.dlang.org/show_bug.cgi?id=14035
Kenji Hara <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #9 from Kenji Hara <[email protected]> --- (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.) ===== To support human natural consequence, I think D built-in type should be categorized as follows: - numeric types: u?byte, u?short, u?int, u?long, [ic]?float, [ic]?double, [ic]?real - character types: [wd]?char - boolean type: bool and disallow conversions beyond the categories for non-polymorphic literals (eg. `4` type with uint). --
