Voting: std.logger

[Marco Leise via Digitalmars-d]

Am Tue, 26 Aug 2014 18:23:30 +0000
schrieb "Dicebot" <public at dicebot.lv>:

> On Tuesday, 26 August 2014 at 15:44:19 UTC, Robert burner Schadek 
> wrote:
> > BTW:
> >   * move std.logger to std.experimental.logger
> >   * the github project has unittests for the version statements 
> > (all pass)
> >
> > whats next?
> 
> I will compare changelist against list of requirements from 
> voters this weekend and if all seems to be addressed will start a 
> new round of review/voting.

Someone else mentioned it before: Logging in destructors would
be a requirement for me, too. Thanks to the GC we usually
don't release memory in them, but "foreign" resources like
e.g. hardware audio playback buffers would typically handled
in a dtor. I see two ways which both require logging:

1) Dtor calls a C function to release the resource, which may
   return an error code, that you want to log. You keep the
   program running since if all else fails you could still
   reinitialize the audio device, thereby releasing all
   buffers.

2) If waiting for the GC to eventually call the dtor is not an
   option because the resource is very limited, you require
   the user to call some .release/.close method. If in the dtor
   the resource is still "open", you log something like
   "WARNING: Destructor called, but audio buffer still
    attached. Call .close() on the last reference."

As much as I see this as non-negotiable, (chancellor Merkel
would have said "alternativlos",) I know it would currently
require the whole log system to be nothrow @nogc and we may
not want to wait till allocating and throwing is allowed
during GC sweeps, before we get std.log.

-- 
Marco