Why is Throwable.TraceInfo.toString not @safe?

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Jul 22 18:38:18 UTC 2019


On Monday, July 22, 2019 1:29:21 AM MDT Johannes Loher via Digitalmars-d-
learn wrote:
> Am 22.07.19 um 05:16 schrieb Paul Backus:
> > On Sunday, 21 July 2019 at 18:03:33 UTC, Johannes Loher wrote:
> >> I'd like to log stacktraces of caught exceptions in an @safe manner.
> >> However, Throwable.TraceInfo.toString is not @safe (or @trusted), so
> >> this is not possible. Why is it not @safe? Can it be @trusted?
> >>
> >> Thanks for your help!
> >
> > Seems like it's because it uses the form of toString that accepts a
> > delegate [1], and that delegate parameter is not marked as @safe.
> >
> > [1] https://dlang.org/phobos/object.html#.Throwable.toString.2
>
> I'm not talking about Throwable's toString method, but about
> Throwable.TraceInfo's. Throwable.TraceInfo is an Interface inside
> Throwable:
>
> interface TraceInfo
> {
>     int opApply(scope int delegate(ref const(char[]))) const;
>     int opApply(scope int delegate(ref size_t, ref const(char[]))) const;
>     string toString() const;
> }
>
> Throwable has a member info of type TraceInfo. It is never explicitly
> set, so I assume it is automatically set by runtime magic. This is the
> constructor of Throwable:
>
> @nogc @safe pure nothrow this(string msg, Throwable nextInChain = null)
> {
>     this.msg = msg;
>     this.nextInChain = nextInChain;
>     //this.info = _d_traceContext();
> }
>
> In theory people could define their own exception classes which provide
> their own implementation of TraceInfo, but I never heard of anybody
> doing this. So the real question is if the toString method of of the
> DRuntime implementations (I assume there might be different
> implementations for different platforms) are actually @safe (or
> @trusted) and why we do not mark the interface to be @safe then.

All of that stuff predates @safe and most if not all attributes. @safe and
the like have been added to some of that stuff, but in some cases, doing so
would break code. I'd have to look at TraceInfo in more detail to know
whether it can reasonably be marked @safe, but if it might end up calling
anything that isn't guaranteed to be @safe, then it probably can't be (e.g.
if it calls Object's toString). Also, TraceInfo is really more for
druntime's use than for your typical programmer to use it directly in their
program. So, I wouldn't be surprised in the least if not much effort was
ever put in to making it @safe-friendly even if it could be. In general,
stuff like @safe has tended to be applied to stuff in druntime and Phobos an
a case-by-case basis, so it's really not surprising when an attribute is
missing when it arguably should be there (though it frequently can't be
there due to stuff like template arguments).

You _do_ need to be very careful with attributes and interfaces/classes
though, because once an attribute is or isn't there, that can lock every
derived class into a particular set of attributes. So, it's not always
straightforward whether an attribute should be present or not. There are
plenty of cases where ideally it would be present, but it can't be (e.g. a
number of functions on TimeZone aren't pure even though they could be for
_most_ derived classes, because they can't be pure for LocalTime), and there
are cases where an attribute should be present but was simply never added. I
don't know where TraceInfo sits, since I haven't dug into it.

- Jonathan M Davis





More information about the Digitalmars-d-learn mailing list