[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