Am Tue, 26 Aug 2014 18:23:30 +0000 schrieb "Dicebot" <pub...@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