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

Dmitry Olshansky dmitry.olsh at gmail.com
Thu Dec 13 11:42:24 PST 2012


12/13/2012 6:25 PM, Simen Kjaeraas пишет:
> 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.
>

User defined implicit conversion should be possible IMO. The reason is a 
proverbial "user-defined types that behave like built-ins" promise that 
D (and many other languages do) but it doesn't hold it yet

Basically we have "explicitly constructed from", and "implicitly 
converts to" but there is yet not provided "implicitly converts from" to 
put it into the seamless interaction with built-ins.

Being a checkable opt-in and staying separate from ctor it won't be as 
readily susceptible to abuse unlike implicit construction in C++ _by 
default_.

> 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?
>



-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list