Example code in std.logger.core doesn't even work

[Jonathan M Davis]

On Wednesday, July 12, 2023 6:29:31 PM MDT mw via Digitalmars-d wrote:
> On Wednesday, 12 July 2023 at 23:11:00 UTC, Jonathan M Davis
>
> wrote:
> >> Sigh, D is so broken on such basic stuff.
> >
> > In general, objects are not supposed to be constructed as
> > shared or even really operated on as shared. ...
> > a shared reference precisely because doing so would not be
> > thread-safe.
> >
> > ...
> >
> > Ultimately, you have to do basically the same stuff in
> > languages like C or C++, but in those languages, you don't have
> > the compiler trying to prevent you from doing anything that
>
> I think the current D confused the users:
>
> 1) why such simple program has compiler errors?
>
>
> https://run.dlang.io/is/2k9Uvu
> ```
> import std.logger;
>
> void main() {
>      std.logger.sharedLog.trace("msg");
> }
>
> ```
>
> 2) it is named `std.logger.sharedLog` from the standard library,
> the users would expect it's thread safe, otherwise, why don't
> just name it `std.logger.Log`, then user would not have such
> wrongful expectations.
>
> 3) if it's not provided at all, or not named that way, the users
> will write their own synchronized thread safe loggers. (Since
> standard library does not provide a ready made one out-of-box).
>
>
> That is why I said: sign, D is so broken on such basic stuff.
>
> The users have to learn it the hard way, and each users have to
> develop their own basic thread safe logging library.

Presumably, it's named sharedLog, because it's shared. Being shared does not
imply thread-safety. It just means that the object is shared across threads,
and that means that the compiler is going to give you error messages when
you try to use it in a way that it can't guarantee is thread-safe (which
usually means getting an error when you try to do much of anything with it,
since very few operations are guaranteed to be thread-safe). How
thread-safety is actually achieved when using a type depends on the API of
that type. It could specifically have a shared API and handle all of the
locking internally (which realistically means that sharedLog would have to
be a different type of object from any thread-local logging objects), or it
could leave the locking mechanism up to the user. For better or worse,
std.logger has done the latter. This provides more flexibility but at the
cost of requiring that the user go to extra effort. I can't really comment
on how good or bad a decision that is, since I've never needed to use
std.logger before and don't usually work on applications that have any need
of functionality of that sort, but I can certainly see why it would be
annoying if you just want to have a logger that works across threads without
having to worry about shared. Realistically though, if you're going to be
doing much with threads in D, you really need to learn the ins and outs of
shared. So, while there's certainly an argument that the current situation
with std.logger is suboptimal, the fact that it's giving an error when
trying to use a shared object is the kind of thing that anyone dealing with
threads in D is going to need to understand.

Regardless, there is no need to create a separate logging library to use
sharedLog. It just means that you either have to provide an appropriate
mutex and deal with locking it yourself, casting away shared, etc., or you
need to put a wrapper around it which takes care of that. std.logger
probably should provide such a wrapper itself, but the fact that it doesn't
doesn't mean that you need to create a whole other solution.

- Jonathan M Davis