Should alias this support implicit construction in function calls and return statements?

[Jonathan M Davis]

On Thursday, December 13, 2012 15:25:10 Simen Kjaeraas wrote:
> As discussed deep in the thread "Is there any reason why arithmetic
> operation
> on shorts and bytes return int?"[1], D currently does not support this
> behavior:
> 
> struct bbyte {
>      byte b;
>      alias b this;
> }
> 
> void foo(bbyte b) {}
> 
> void baz() {
>      byte b;
>      foo(b); // Cannot implicitly convert byte to bbyte.
> }
> 
> bbyte baz( ) {
>      byte b;
>      return b; // Cannot implicitly convert byte to bbyte.
> }
> 
> Kenji Hara points out, and I myself thought, that this was a deliberate
> design choice. Walter's post[2] in the aforementioned thread indicates
> (but does not make clear-cut) that he also thinks this implicit
> construction is desirable.
> 
> A previous discussion with Andrei[3] about implicit conversion of nameless
> tuples to named tuples resulted in a bug report[4], and it is clear that
> his view also supports some such form of implicit conversion.
> 
> A long time ago, when dinosaurs roamed the earth, walterandrei.pdf[5]
> suggested that opImplicitCastTo and opImplicitCastFrom take care of this
> conversion. Is anything like this still on the drawing board? Should alias
> this do it? How do we deal with cases were one field is alias this'd, and
> other fields are not?

I don't see any reason not to support it. if you want coversion to only go one 
way, then alias a function which returns the value being aliased rather than 
aliasing a variable. If it doesn't support implicit conversions from other 
types, then it's impossible to have such implicit conversion in D, and I don't 
see any reason why it should be disallowed like that, not when you've 
explicitly said that you want to do an alias like that.

- Jonathan M Davis