In D it's not possible to make opCast operators implicit.
Therefore I see no way of making "transparent wrappers"; like
structs which could be used as a drop-in replacement for plain
old data types.

E.g if I wanted to make a SafeInt struct, that behaves otherwise
just like an int, but when operators like +=, *=, ++, -- etc are
used with it, my custom SafeInt operators would check that
there's no integer overflow. If you use alias this to _reveal_
the internal int value of SafeInt, then that int value's default
operators are used, and thus no overflow checking.

I find the lack of implicit casting a defect of the language.
I hope that I'm wrong.

"Tommi" , dans le message (digitalmars.D:174314), a écrit :
> In D it's not possible to make opCast operators implicit. Therefore I see no way of making "transparent wrappers"; like structs which could be used as a drop-in replacement for plain old data types.
> 
> E.g if I wanted to make a SafeInt struct, that behaves otherwise just like an int, but when operators like +=, *=, ++, -- etc are used with it, my custom SafeInt operators would check that there's no integer overflow. If you use alias this to _reveal_ the internal int value of SafeInt, then that int value's default operators are used, and thus no overflow checking.
> 
> I find the lack of implicit casting a defect of the language. I hope that I'm wrong.

Does alias this not fullfill you goal? http://dlang.org/class.html#AliasThis

On Mon, 06 Aug 2012 15:29:47 +0200, Tommi <tommitissari@hotmail.com> wrote:

> If you use alias this to _reveal_
> the internal int value of SafeInt, then that int value's default
> operators are used, and thus no overflow checking.

No.

-- 
Simen

> E.g if I wanted to make a SafeInt struct, that behaves otherwise
> just like an int, but when operators like +=, *=, ++, -- etc are
> used with it, my custom SafeInt operators would check that
> there's no integer overflow.

> If you use alias this to _reveal_
> the internal int value of SafeInt, then that int value's default
> operators are used, and thus no overflow checking.

Wouldn't you have the exact same problem with implicit casts in C++? If you want to use custom operators, you should just define those, same as you would in C++. You can even implement just some operators and use alias this for functionality that you don't want to reimplement, like this:

import std.stdio;

struct A
{
    int a;
    alias a this;
    auto opOpAssign(string op, T)(T b)
        if(op == "+" && is(typeof(a += T.init)))
    {
        a += b;
        writeln("opOpAssign!\"+\" called.");
    }
}


void main()
{
    auto a = A(3);
    a += 5u;
    writeln(a);
    writeln(a - 1);
}

This prints:

opOpAssign!"+" called.
8
7

On Monday, 6 August 2012 at 13:59:30 UTC, jerro wrote:
> Wouldn't you have the exact same problem with implicit casts in C++? If you want to use custom operators, you should just define those, same as you would in C++. You can even implement just some operators and use alias this for functionality that you don't want to reimplement, like this:
>
> import std.stdio;
>
> struct A
> {
>     int a;
>     alias a this;
>     auto opOpAssign(string op, T)(T b)
>         if(op == "+" && is(typeof(a += T.init)))
>     {
>         a += b;
>         writeln("opOpAssign!\"+\" called.");
>     }
> }
>
>
> void main()
> {
>     auto a = A(3);
>     a += 5u;
>     writeln(a);
>     writeln(a - 1);
> }
>
> This prints:
>
> opOpAssign!"+" called.
> 8
> 7

Oh... I've had a pretty longstanding misunderstanding then. I tested something like that a while ago, and didn't manage to get the custom operator called. Instead the aliased type's default operator was called. Then I assumed that's how alias this worked. I must have done something wrong back then, I don't know, can't find that test code anymore.

On 08/06/12 15:29, Tommi wrote:
> In D it's not possible to make opCast operators implicit. Therefore I see no way of making "transparent wrappers"; like structs which could be used as a drop-in replacement for plain old data types.
> 
> E.g if I wanted to make a SafeInt struct, that behaves otherwise just like an int, but when operators like +=, *=, ++, -- etc are used with it, my custom SafeInt operators would check that there's no integer overflow. If you use alias this to _reveal_ the internal int value of SafeInt, then that int value's default operators are used, and thus no overflow checking.

There's sort-of limited support for implicit-casts - 'alias this' with a getter. That does not force exposure of the internal representation, but has other problems. The main one is of course that there can only be one 'alias this'.

> I find the lack of implicit casting a defect of the language.

Yes.

> I hope that I'm wrong.

You are not.

artur

On 08/06/2012 08:08 AM, Artur Skawina wrote:

> There's sort-of limited support for implicit-casts - 'alias this'
> with a getter. That does not force exposure of the internal
> representation, but has other problems. The main one is of course
> that there can only be one 'alias this'.

Luckily, it's just a lack of implementation:

  http://d.puremagic.com/issues/show_bug.cgi?id=6083

Ali