Voting: std.logger

[Marco Leise via Digitalmars-d]

Am Sun, 31 Aug 2014 08:52:58 +0000
schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang at gmail.com>:

> On Sunday, 31 August 2014 at 06:11:56 UTC, Marco Leise wrote:
> > Am Sun, 31 Aug 2014 01:09:32 +0000
> > schrieb "Ola Fosheim Grøstad"
> > <ola.fosheim.grostad+dlang at gmail.com>:
> 
> >> How does logging interact with pure? You need to be able to 
> >> log in pure functions.
> >
> > How do you come to that conclusion? Purity is a synonym for
> > _not_ having side effects. That said - as usual - "debug"
> > statements allow you to punch a hole into purity.
> 
> 1. ~90% of all functions are weakly pure, if you cannot log 
> execution in those functions then logging becomes a liability.
>
> 2. If you define logging in a weakly pure function as tracing of 
> execution rather than logging of state, then you can allow 
> memoization too.

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".
 
> 3. You don't normally read back the log in the same execution, 
> state is thus not preserved through logging within a single 
> execution. It has traits which makes it less problematic than 
> general side effects that change regular global variables.

I still don't see it fly even theoretically. The "stdlog" will
be an interface with an arbitrary implementation behind it. A
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.
It is much like discussing the strictness of transitive const.
If you need to cache values of initialize on first access, you
just have to drop const.

-- 
Marco