www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should alias this support implicit construction in function calls and

reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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?


[1]:  
http://forum.dlang.org/thread/mailman.2599.1355228650.5162.digitalmars-d puremagic.com?page=3#post-mailman.2625.1355305365.5162.digitalmars-d:40puremagic.com

[2]:  
http://forum.dlang.org/thread/mailman.2599.1355228650.5162.digitalmars-d puremagic.com?page=3#post-kaatc0:24hgn:242:40digitalmars.com

[3]:  
http://forum.dlang.org/thread/sedknwtlaefrxuflnbez forum.dlang.org?page=8#postjul0qv:242l9d:241:40digitalmars.com

[4]: http://d.puremagic.com/issues/show_bug.cgi?id=8570

[5]: http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf


-- 
Simen
Dec 13 2012
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 13 December 2012 at 14:25:27 UTC, Simen Kjaeraas 
wrote:
     foo(b); // Cannot implicitly convert byte to bbyte.

I think the way it is now is correct for alias this.. it is kinda like implicitly casting to a base class. That's correct, but going to a superclass isn't necessarily right. You might only want it to be one way. Suppose you had something like this: struct SafeText { string text; alias this text; } Safe text should implicitly convert to plain string text, but it shouldn't go the other way automatically.
 A long time ago, when dinosaurs roamed the earth, 
 walterandrei.pdf[5] suggested that opImplicitCastTo and 
 opImplicitCastFrom take care of this conversion.

A separate function or facility for implicit cast to might be ok though.
Dec 13 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-38-13 15:12, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Thursday, 13 December 2012 at 14:25:27 UTC, Simen Kjaeraas wrote:
     foo(b); // Cannot implicitly convert byte to bbyte.

I think the way it is now is correct for alias this.. it is kinda like implicitly casting to a base class. That's correct, but going to a superclass isn't necessarily right. You might only want it to be one way. Suppose you had something like this: struct SafeText { string text; alias this text; } Safe text should implicitly convert to plain string text, but it shouldn't go the other way automatically.

But this is easily solved: struct SafeText { string text; string get( ) property { return text; } alias get this; } This is just as explicit as what you propose, and possible with what we currently have.
 A long time ago, when dinosaurs roamed the earth, walterandrei.pdf[5]  
 suggested that opImplicitCastTo and opImplicitCastFrom take care of  
 this conversion.

A separate function or facility for implicit cast to might be ok though.

-- Simen
Dec 13 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 13 December 2012 at 16:15:16 UTC, Simen Kjaeraas 
wrote:
 But this is easily solved:

Hmmm, indeed. This might just work then...
Dec 13 2012
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Dec 13 2012