struct A {}
class B {
	A opCast(T : A)() {
		return A();
	}
}
void main() {
	auto b = new B();
	destroy(b);
}

fails with

dmd2\windows\bin\..\..\src\druntime\import\object.d(4209): Error: template instance `opCast!(void*)` does not match template declaration `opCast(T : A)()`
main.d(9): Error: template instance `object.destroy!(true, B)` error instantiating

Looks like a similar bug has been reported: https://issues.dlang.org/show_bug.cgi?id=22635

As a workaround, adding an additional opCast:

class B {
	A opCast(T : A)() {
		return A();
	}
	auto opCast(T)() {
		return cast(T)super;
	}
}

SEEMS to work. Is that safe? Or are consequences not what I'm intending?

On Tuesday, 1 March 2022 at 04:29:56 UTC, cc wrote:

struct A {}
class B {
	A opCast(T : A)() {
		return A();
	}
}
void main() {
	auto b = new B();
	destroy(b);
}

dmd2\windows\bin\..\..\src\druntime\import\object.d(4209): Error: template instance `opCast!(void*)` does not match template declaration `opCast(T : A)()`
main.d(9): Error: template instance `object.destroy!(true, B)` error instantiating

Is it a bug? It's not documented in the opCast documentation, but it looks like when you define an opCast it completely replaces the default behavior, i.e., whatever type you define as the target type becomes the only type to which you can attempt to cast.

It makes sense to me, and I would say the bug is that it's not documented.

class B {
	A opCast(T : A)() {
		return A();
	}
	auto opCast(T)() {
		return cast(T)super;
	}
}

So what you've done here is specialized on anything convertible to A and then reenabled casts to all other types, i.e., the default behavior, but with a special exception for T:A.

You could also specialize on void*, as that's the type that was failing to compile. Then you're restricted to void* and anything convertible to A.

On Tuesday, 1 March 2022 at 04:59:49 UTC, Mike Parker wrote:

I meant "instead", not also.

On Tuesday, 1 March 2022 at 04:59:49 UTC, Mike Parker wrote:

Personally it doesn't make sense to me. I don't think it should override default behaviors, but just add onto it, so you can add an additional cast.

Right now if you want to add an additional cast then you have to implement ALL the default behaviors and then add your custom cast.

That doesn't seem correct to me at least.

That's not how the behavior is in most other languages either.

On Tuesday, 1 March 2022 at 07:16:11 UTC, bauss wrote:

It's two template functions like the OP used: one for T to catch everything, and one specialization.

Depends on your perspective I guess. For the inverse, when you want to allow only one kind of cast and prevent everything else, you only have to implement one template right now. If that were not the case, then you'd have to implement an additional catch-all template that bombs out with a static assert.

So either way makes sense, IMO. Though I totally understand how the current behavior can be a surprise when people expect it to behave like, e.g., C++.

But D is not C++. So is opCast intended to expand the list of target types (like C++), or is it intended to define it? The spec says, "To define how one type can be cast to another", which doesn't really answer the question.

On Tuesday, 1 March 2022 at 08:16:13 UTC, Mike Parker wrote:

Now is possible this:

import std.stdio;

    struct Foo{
        int i;

        this(int i)@safe{
        	this.i = i;
            writeln("ctor(", i, "): ", cast(void*)&this);
        }

        Foo opCast(T, this This)()@safe
        if(is(immutable T == immutable This)){
            return Foo(2);
        }

        ~this()@safe{
        	writeln("dtor(", i, "): ", cast(void*)&this);
        }
    }

    struct Bar{
        const Foo foo;

        this(int i)@safe{
        	this.foo = Foo(i);
        }
    }

    void main()@safe{
        Bar bar =  Bar(1);
    }

Result:

ctor(1): 7FFE0D5A94A8  //dtor for Foo(1) is never called.
ctor(2): 7FFE0D5A9410
dtor(2): 7FFE0D5A9470
dtor(2): 7FFE0D5A9470  //dtor for Foo(2) is called twice.

On Tuesday, 1 March 2022 at 08:16:13 UTC, Mike Parker wrote:

Yes of course it's a matter of perspective.

I think the solution would be to have two functions for opCast, maybe something like opAdditionalCast, idk, not to break current behavior I guess.

On Tuesday, 1 March 2022 at 04:59:49 UTC, Mike Parker wrote:

struct A {}
class B {
	A opCast(T : A)() {
		return A();
	}
}
void main() {
	auto b = new B();
	destroy(b);
}

dmd2\windows\bin\..\..\src\druntime\import\object.d(4209): Error: template instance `opCast!(void*)` does not match template declaration `opCast(T : A)()`
main.d(9): Error: template instance `object.destroy!(true, B)` error instantiating

It's a bug in druntime. destroy needs to reinterpret the class reference as a void* to pass it to rt_finalize:

https://github.com/dlang/druntime/blob/v2.098.1/src/object.d#L4209

However, cast(void*) is not the correct way to do this, because it fails in the presence of opCast.

On Tuesday, 1 March 2022 at 16:40:50 UTC, Paul Backus wrote:

https://github.com/dlang/druntime/pull/3766