digitalmars.D.learn - Cast to left hand side
- tcak (15/15) Nov 09 2014 In some cases, I need to cast right hand side expression to left
- eles (19/27) Nov 09 2014 I am also strongly in favor of introducing an "uncast". For
- ketmar via Digitalmars-d-learn (3/39) Nov 09 2014 i believe you can do this with some template magic.
- bearophile (8/13) Nov 09 2014 I think this is supposed to work:
- ketmar via Digitalmars-d-learn (5/20) Nov 09 2014 On Sun, 09 Nov 2014 22:17:33 +0000
- tcak (6/25) Nov 09 2014 Well, my question was actually on-purpose automatic casting.
- eles (6/11) Nov 10 2014 Is not the same. Auto or not, this is still an explicit cast. I
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (34/36) Nov 09 2014 'alias this' can do that but unfortunately, the current compiler
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
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
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:i believe you can do this with some template magic.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.
Nov 09 2014
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
On Sun, 09 Nov 2014 22:17:33 +0000 bearophile via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:eles: =20it works for simple types, like 'immutable int a'. but for 'immutable(int*) a' it returns 'immutable(int)* a'.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; }
Nov 09 2014
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
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
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