www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Cast to left hand side

reply "tcak" <tcak gmail.com> writes:
In some cases, I need to cast right hand side expression to left 
hand side. While it looks/feels simple for basic data types, it 
requires long lines with duplication when flexible code is 
desired to be written.

Example:

int a = 7;
byte b;

b = cast( byte )a;


When I want to create a system where data types should match each 
other automatically, my code turns into this.

b = cast( typeof( b ) )a;


Alright, in my use cases, variable names "a" and "b" are long 
with module names mostly.

Is there any way to cast to type of left hand side variable the 
right side?
Nov 09 2014
next sibling parent reply "eles" <eles eles.com> writes:
On Sunday, 9 November 2014 at 19:00:01 UTC, tcak wrote:
 In some cases, I need to cast right hand side expression to 
 left hand side. While it looks/feels simple for basic data 
 types, it requires long lines with duplication when flexible 
 code is desired to be written.

 Example:

 int a = 7;
 byte b;

 b = cast( byte )a;
I am also strongly in favor of introducing an "uncast". For example, in C++'x const_cast and in D's cast for removing, for example immutability: immutable int* p = ...; int* q = cast(int*)p; I think the goal is not clearly expressed with this cast. It does not show that it's intension is to remove immutability and otherwise let that type unchanged. If later a mismatch is introduced between the left and the right type of data, that inoffensive cast could create problems by hiding an error that should have been spotted. Something like that would be more expressive: immutable int* p = ...; int* q = uncast(immutable)p; //or int* q = cast(~immutable)p; This way, invalid implicit conversions from p's type to q's type would be spotted.
Nov 09 2014
next sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sun, 09 Nov 2014 21:47:02 +0000
eles via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:

 On Sunday, 9 November 2014 at 19:00:01 UTC, tcak wrote:
 In some cases, I need to cast right hand side expression to=20
 left hand side. While it looks/feels simple for basic data=20
 types, it requires long lines with duplication when flexible=20
 code is desired to be written.

 Example:

 int a =3D 7;
 byte b;

 b =3D cast( byte )a;
=20 I am also strongly in favor of introducing an "uncast". For=20 example, in C++'x const_cast and in D's cast for removing, for=20 example immutability: =20 immutable int* p =3D ...; int* q =3D cast(int*)p; =20 I think the goal is not clearly expressed with this cast. It does=20 not show that it's intension is to remove immutability and=20 otherwise let that type unchanged. If later a mismatch is=20 introduced between the left and the right type of data, that=20 inoffensive cast could create problems by hiding an error that=20 should have been spotted. =20 Something like that would be more expressive: =20 immutable int* p =3D ...; int* q =3D uncast(immutable)p; //or int* q =3D cast(~immutable)p; =20 This way, invalid implicit conversions from p's type to q's type=20 would be spotted.
i believe you can do this with some template magic.
Nov 09 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
eles:

 I am also strongly in favor of introducing an "uncast". For 
 example, in C++'x const_cast and in D's cast for removing, for 
 example immutability:

 immutable int* p = ...;
 int* q = cast(int*)p;
I think this is supposed to work: void main() { immutable int* p; int* q = cast()p; } Bye, bearophile
Nov 09 2014
parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sun, 09 Nov 2014 22:17:33 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:

 eles:
=20
 I am also strongly in favor of introducing an "uncast". For=20
 example, in C++'x const_cast and in D's cast for removing, for=20
 example immutability:

 immutable int* p =3D ...;
 int* q =3D cast(int*)p;
=20 I think this is supposed to work: =20 void main() { immutable int* p; int* q =3D cast()p; }
it works for simple types, like 'immutable int a'. but for 'immutable(int*) a' it returns 'immutable(int)* a'.
Nov 09 2014
prev sibling parent reply "tcak" <tcak gmail.com> writes:
On Sunday, 9 November 2014 at 21:47:03 UTC, eles wrote:
 On Sunday, 9 November 2014 at 19:00:01 UTC, tcak wrote:

 I am also strongly in favor of introducing an "uncast". For 
 example, in C++'x const_cast and in D's cast for removing, for 
 example immutability:

 immutable int* p = ...;
 int* q = cast(int*)p;

 I think the goal is not clearly expressed with this cast. It 
 does not show that it's intension is to remove immutability and 
 otherwise let that type unchanged. If later a mismatch is 
 introduced between the left and the right type of data, that 
 inoffensive cast could create problems by hiding an error that 
 should have been spotted.

 Something like that would be more expressive:

 immutable int* p = ...;
 int* q = uncast(immutable)p;
 //or
 int* q = cast(~immutable)p;

 This way, invalid implicit conversions from p's type to q's 
 type would be spotted.
Well, my question was actually on-purpose automatic casting. Something like: b = autocast( a ); Because I am auto casting with a keyword, compiler shouldn't complain about it as well. This can also solve "uncast" thing.
Nov 09 2014
parent "eles" <eles eles.com> writes:
On Monday, 10 November 2014 at 05:00:25 UTC, tcak wrote:
 On Sunday, 9 November 2014 at 21:47:03 UTC, eles wrote:
 On Sunday, 9 November 2014 at 19:00:01 UTC, tcak wrote:
 Because I am auto casting with a keyword, compiler shouldn't 
 complain about it as well. This can also solve "uncast" thing.
Is not the same. Auto or not, this is still an explicit cast. I was asking for a cast to be limited to the attribute that is targeted, and let data format unchanged. The two are fairly different notions, because one specifies the format of the data, the other specifies permissions on that data.
Nov 10 2014
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/09/2014 10:59 AM, tcak wrote:

 When I want to create a system where data types should match
 each other automatically,
'alias this' can do that but unfortunately, the current compiler supports only one 'alias this' in a user-defined type. I think that limitation will be gone with 2.067. Although the following functions return rvalues, 'alias this' can use member variables as well: alias myMemberVariable this; import std.stdio; struct A { B asB() { writeln(__FUNCTION__); return B(); } alias asB this; } struct B { A asA() { writeln(__FUNCTION__); return A(); } alias asA this; } void main() { A a; B b; b = a; a = b; } Ali
Nov 09 2014