Voting: std.logger

[via Digitalmars-d]

On Sunday, 31 August 2014 at 09:34:51 UTC, Marco Leise wrote:
> Ok, here is the current state: Logging is not a first-class
> language feature with special semantics. Drop your "pure"
> keywords on those 90% of functions or only log in "debug".

Then maybe the language lacks features that allow you to escape 
purity in a safe manner.

But maybe you should only allow "trace()" and not "log()" in pure 
functions. Tracing execution and logging state.

> I still don't see it fly even theoretically. The "stdlog" will
> be an interface with an arbitrary implementation behind it.

An interface can require specific properties of the 
implementation.

> file logger will eventually hit a "disk full" state and throw
> an exception. Since "pure" implies that a function call can be
> elided such a change of execution path cannot work.

Not sure what you mean by this.

The logger I am most interested in writes to a circular buffer 
and uploads the log to a database on a crash so that the source 
of the crash can be identified. I am only interested in in 
logging execution, not preserved state without execution.

It is not uncommon to have loggers that writes to a fixed size 
preallocated area that behaves like a circular buffer (e.g. 
retain at most 1GB and <3 months old logging-data)