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)
