[Issue 14035] string concatenation accepts ints in templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14035

--- Comment #12 from yebblies <yebblies at gmail.com> ---
(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;

--