should int/short/byte implicitly cast to dchar/wchar/char?

[Jonathan M Davis]

On 2011-05-16 12:47, KennyTM~ wrote:
> On May 17, 11 02:25, Steven Schveighoffer wrote:
> > On Mon, 16 May 2011 13:51:55 -0400, Steven Schveighoffer
> > 
> > <schveiguy at yahoo.com> wrote:
> >> Currently, this works:
> >> 
> >> void foo(dchar i)
> >> {
> >> }
> >> 
> >> void main(string[] args)
> >> {
> >> foo(args.length);
> >> }
> > 
> > Damn, this originally started out as argc and argv, and I forgot how D
> > accepts arguments, so I switched it to this. Unsigned ints are
> > convertable to dchar, but signed ones are not (except for a couple
> > cases, which doesn't make sense).
> > 
> > For example, this fails:
> > 
> > dchar c = -1;
> > foo(-1);
> 
> This fails because the compiler can check in compile-time that
> 0xffff_ffff is > 0x10_ffff....
> 
> > But this passes:
> > 
> > int i = -1;
> > dchar c = i;
> 
> ....but this cannot. 'dchar' should be treated as lower-rank than 'int'
> and use value-range propagation on it.

I'd argue that assigning an int to a dchar should fail in all cases where 
there is no cast and where the compiler cannot use value-range propogation to 
verify that the value being assigned to the dchar is a valid value for a 
dchar. So, in the above case, if the compiler fails to do value-range 
propagation for some reason (which it shouldn't in a case this small), the 
assignment should be illegal, because there is no cast. And if the compiler 
manages to do value-range propagation (as it should), then it should still 
fail, because -1 is not a value value for a dchar.

- Jonathan M Davis