On Sunday, 13 July 2014 at 12:12:46 UTC, Dicebot wrote:
> On Sunday, 13 July 2014 at 11:57:26 UTC, Robert burner Schadek wrote:
>>> - The functions error(), info(), fatal(), etc. don't follow the usual rule for functions to start with a verb. The question is if saving three characters over logError() is worth making the code more ambiguous for the outside reader (e.g. "does error() throw an exception? or set some internal error state?" "does fatal() terminate the process?")
>>
>> if I change it back, people will argue that that is redundant and unintuitive. Than I will change it back again and the discussion starts again.
>
> I think those functions are used so often that can be worth an exception.

+1

And it has precursors in other logging APIs.

>>> * there is no reason to limit it arbitrarily
>>
>> Simple is better than complex.
> it is hardly complex

Of course it is... wasn't this one of the main reasons you chose
the mixin solution?

On Sunday, 13 July 2014 at 14:12:56 UTC, Jacob Carlborg wrote:
> On 2014-07-13 14:45, Dicebot wrote:
>
>> Exactly. I think this should be popularized as default style via
>> std.logger documentation.
>
> If that's the style everyone is encouraged to use, why not force it then?

Because starting with documentation in Phobos and than proceeding with convincing Walter to add built-in support for such idiom is much more realistic way than the other way around ;)

On Sunday, 13 July 2014 at 15:12:19 UTC, Dragos Carp wrote:
>>>> * there is no reason to limit it arbitrarily
>>>
>>> Simple is better than complex.
>> it is hardly complex
>
> Of course it is... wasn't this one of the main reasons you chose
> the mixin solution?

no, I find typing nearly the same function over and over stupidly boring and error prone

On Sunday, 13 July 2014 at 14:37:15 UTC, Robert burner Schadek wrote:
>> I would prefer:
>>   info("%s is the answer", true);
> write infof("%b is the answer", true); and it works write now arbitrarily

I am kind of fine both ways, it is not that big deal but I remember being very surprised that most common use case is called `logf` and much less common - `log`. For `write` function family common usage pattern is a bit different.

In the end it boils down to "consistency" vs "convenience" argument and I don't think either has fundamental advantage over the other. Sticking to whatever Robert prefers is reasonable way to avoid hundreds post long bike-shedding ;)

On Sunday, 13 July 2014 at 15:19:19 UTC, Robert burner Schadek wrote:
> On Sunday, 13 July 2014 at 15:12:19 UTC, Dragos Carp wrote:
>>>>> * there is no reason to limit it arbitrarily
>>>>
>>>> Simple is better than complex.
>>> it is hardly complex
>>
>> Of course it is... wasn't this one of the main reasons you chose
>> the mixin solution?
>
> no, I find typing nearly the same function over and over stupidly boring and error prone

When it comes to public API having perfect documentation is much more important in my opinion - one can still mixin the bodies but repeating signatures is lesser of evils.

> I am kind of fine both ways, it is not that big deal but I remember being very surprised that most common use case is called `logf` and much less common - `log`. For `write` function family common usage pattern is a bit different.

If we get rid of the write style variant, then you need to
remember just one name with 4 overloads:

log(string message);
log(string format, Args...);
log(bool condition, string message);
log(bool condition, string format, Args...);

This is a library: you can always add names, but it is very hard
to remove them. If next version of std.logger should support
something like logFirstN or logEveryN (ideas from Google log
library). How this should look like? logfnf, logenf...?

On Sunday, 13 July 2014 at 16:02:05 UTC, Dragos Carp wrote:
>
>> I am kind of fine both ways, it is not that big deal but I remember being very surprised that most common use case is called `logf` and much less common - `log`. For `write` function family common usage pattern is a bit different.
>
> If we get rid of the write style variant, then you need to
> remember just one name with 4 overloads:
>
> log(string message);
> log(string format, Args...);
> log(bool condition, string message);
> log(bool condition, string format, Args...);

It had that, it was to little for users.

>
> This is a library: you can always add names, but it is very hard
> to remove them. If next version of std.logger should support
> something like logFirstN or logEveryN (ideas from Google log
> library). How this should look like? logfnf, logenf...?

c++ does not have foreach(i; 1 .. n)

>>
>> This is a library: you can always add names, but it is very hard
>> to remove them. If next version of std.logger should support
>> something like logFirstN or logEveryN (ideas from Google log
>> library). How this should look like? logfnf, logenf...?
>
> c++ does not have foreach(i; 1 .. n)

Sorry that I didn't described how logFirstN and logEveryN work.

Let say you output a log in a loop with 100 iterations.
logFirstN(10, ...) outputs the log message just for the first 10
iterations, and logEveryN(10, ...)  outputs only for 1st, 11th,
21st, .. and 91st iterations.

On Sunday, 13 July 2014 at 16:44:21 UTC, Dragos Carp wrote:
> Let say you output a log in a loop with 100 iterations.
> logFirstN(10, ...) outputs the log message just for the first 10
> iterations, and logEveryN(10, ...)  outputs only for 1st, 11th,
> 21st, .. and 91st iterations.

In D, we can easily make this syntax every!(10, log)(…) or something along the lines, sidestepping any naming problems and also allowing for more flexibility at the same time.

David