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?

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.

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 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.
i believe you can do this with some template magic.

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

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.

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

On Sun, 09 Nov 2014 22:17:33 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> 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;
> }
it works for simple types, like 'immutable int a'. but for
'immutable(int*) a' it returns 'immutable(int)* a'.

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.