Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception.toString not useable in @safe #20573

Open
braddr opened this issue Dec 18, 2024 · 4 comments
Open

Exception.toString not useable in @safe #20573

braddr opened this issue Dec 18, 2024 · 4 comments
Labels
Druntime Specific to druntime

Comments

@braddr
Copy link
Member

braddr commented Dec 18, 2024

This code (extracted from a larger project):

module safety;

import core.sys.posix.stdio : printf;
import std.exception;

void main() @safe
{
    try
    {
        throw new Exception("irrelevant");
    }
    catch (Exception e)
    {
        string s = e.toString();
    }
}

Results in:

safety.d(14): Error: `@safe` function `D main` cannot call `@system` function `object.Throwable.toString`
/home/braddr/sandbox/dmd.2.109.1/linux/bin64/../../src/druntime/import/object.d(2652):        `object.Throwable.toString` is declared here
@braddr braddr transferred this issue from dlang/dmd Dec 18, 2024
@0xEAB
Copy link
Member

0xEAB commented Dec 18, 2024

@braddr transferred this issue from dlang/dmd Dec 18, 2024

Isn’t this rather a druntime thing than a Phobos one?

@thewilsonator thewilsonator transferred this issue from dlang/phobos Dec 18, 2024
@thewilsonator
Copy link
Contributor

Yes

@braddr
Copy link
Member Author

braddr commented Dec 18, 2024

oops.. forgot that druntime was moved to the dmd repo. I moved it out since it wasn't a dmd issue, but you're correct.

@thewilsonator thewilsonator added the Druntime Specific to druntime label Dec 18, 2024
@jmdavis
Copy link
Member

jmdavis commented Dec 18, 2024

Yeah, this falls under the general set of issues that come from these functions being on Object - and being there from before @safe was even a thing to boot - though even if Object didn't have it, Exception would then have to introduce it into its own hierarchy, and that creates some of the same problems.

If we made toString be @safe, then that would break existing code. It would also force all implementations to be @safe or @trusted - which may not be unreasonable, but I don't think that we can make that change at this point. We may be able to change it with editions at some point, though attributes are always going to be a problem in a situation like this, since putting them on the base class function puts restrictions on the entire class hierarchy - which is probably reasonable in the case of @safe but considerably less so with most of the others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Druntime Specific to druntime
Projects
None yet
Development

No branches or pull requests

4 participants