Thread overview
September 19
https://issues.dlang.org/show_bug.cgi?id=24772

Richard (Rikki) Andrew Cattermole <alphaglosined@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alphaglosined@gmail.com

--- Comment #1 from Richard (Rikki) Andrew Cattermole <alphaglosined@gmail.com> ---
The only thing you can do once you cast it is cause program corruption.

Is there a benefit to being able to do this in ``@safe`` that I am not aware of?

--
September 19
https://issues.dlang.org/show_bug.cgi?id=24772

--- Comment #2 from Georgy Markov <ogion.art@gmail.com> ---
(In reply to Richard (Rikki) Andrew Cattermole from comment #1)
> The only thing you can do once you cast it is cause program corruption.

interface MyCOMInterface : IUnknown
{
    /*...*/
}

MyCOMInterface comObject;
CoCreateInstance(
    &clsid,
    null,
    CLSCTX_INPROC_SERVER,
    &iid,
    &cast(void*)comObject,
);

--
September 19
https://issues.dlang.org/show_bug.cgi?id=24772

--- Comment #3 from Richard (Rikki) Andrew Cattermole <alphaglosined@gmail.com> ---
That code is unsafe.

You have lost the type system guarantees, calling into unknown code.

Which yes, if you passed the wrong arguments could have led to program corruption.

--
September 19
https://issues.dlang.org/show_bug.cgi?id=24772

--- Comment #4 from Georgy Markov <ogion.art@gmail.com> ---
(In reply to Richard (Rikki) Andrew Cattermole from comment #3)
> 
> You have lost the type system guarantees, calling into unknown code.
> 
> Which yes, if you passed the wrong arguments could have led to program corruption.

Irrelevant. The cause of possible memory corruption is function call, not pointer conversion.

--
September 19
https://issues.dlang.org/show_bug.cgi?id=24772

--- Comment #5 from Richard (Rikki) Andrew Cattermole <alphaglosined@gmail.com> ---
It is relevant because I am asking for justification of what you can do with it after casting which would also be @safe.

Right now, we have no examples of this being a positive change, only negative ones.

--
September 19
https://issues.dlang.org/show_bug.cgi?id=24772

Tim <tim.dlang@t-online.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tim.dlang@t-online.de

--- Comment #6 from Tim <tim.dlang@t-online.de> ---
(In reply to Richard (Rikki) Andrew Cattermole from comment #1)
> The only thing you can do once you cast it is cause program corruption.
> 
> Is there a benefit to being able to do this in ``@safe`` that I am not aware of?

One use case is printing the address of an object:
```
    auto o = new Object();
    writeln(cast(void*) o);
```

Addresses could also be compared for equality or used as keys in associative arrays.

--
September 19
https://issues.dlang.org/show_bug.cgi?id=24772

--- Comment #7 from Richard (Rikki) Andrew Cattermole <alphaglosined@gmail.com> ---
That does establish some casting should be valid.

I.e.

```d
import std.stdio;

void main() {
    writeln(cast(size_t)cast(void*)new Object);
}
```

--
September 20
https://issues.dlang.org/show_bug.cgi?id=24772

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang@jmdavisProg.co
                   |                            |m

--- Comment #8 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
As a general rule, if we can guarantee that something is memory safe, it should be @safe. The general issue is being absolutely certain that something cannot result in memory corruption in @safe code. So, we do need to be careful in verifying that.

However, if we are 100% sure that something will not result in violating memory safety in purely @safe code, we arguably should enable it, and I'm not sure if it really matters whether it clearly enables anything.

For this particular case, if the void* is immediately passed to something @system, then the @safety doesn't really matter, because you'll need to slap @trusted on it all anyway. However, if there is a use case where the class is converted to void* in a separate piece of code, then it's arguably just annoying to required @trusted in that part of the code.

But I've certainly run into the case where I have to slap @trusted on code or use debug {} just because I'm trying to print out the pointer value of a class reference.

--
October 02
https://issues.dlang.org/show_bug.cgi?id=24772

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkorpel@live.nl

--- Comment #9 from Dennis <dkorpel@live.nl> ---
When I made a PR for this, it got closed for a reason which couldn't be specified.

"There was a reason this was marked as unsafe, unfortunately I can't recall at the moment what it was."

https://github.com/dlang/dmd/pull/10672

I personally don't believe it's unsafe however.

--