[Issue 14035] string concatenation accepts ints in templates
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Sat Mar 21 22:53:47 PDT 2015
https://issues.dlang.org/show_bug.cgi?id=14035
Kenji Hara <k.hara.pg at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WONTFIX |---
--- Comment #9 from Kenji Hara <k.hara.pg at gmail.com> ---
(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).
--
More information about the Digitalmars-d-bugs
mailing list