On Tuesday, 29 July 2014 at 12:18:31 UTC, Robert burner Schadek wrote:
> maybe we should have made a vote for logc vs. log(bool) first
>
> I think we gone full circle ulong.max times by now  ;-)

This shouldn't affect inclusion to std.experimental and can be done at any moment

On Tuesday, 29 July 2014 at 05:11:33 UTC, Dicebot wrote:
> 1) Yes / No for inclusion into std.experimental
Yes, absolutely.

> 2) Yes / No for inclusion into Phobos in its current state
Not yet.

> 3) If you have answered "No" for (2) :  list of mandatory changes that
> are needed to make you vote "Yes"
As far as I undestood, there's no way right now to do logging without using the GC. And that means it is currently impossible to log inside destructor calls. That is a blocker in my book.

> 4) Any additional comments for author.
No matter the changes that might be applied to reduce suffix notation, I would love to retain the ability to do conditional unformatted logging.

On Tue, 29 Jul 2014 05:11:31 +0000, Dicebot wrote:

> 1) Yes / No for inclusion into std.experimental

Yes

> 2) Yes / No for inclusion into Phobos in its current state

No

see notes in (3)

> 3) If you have answered "No" for (2) :  list of mandatory changes that
> are needed to make you vote "Yes"

We need to hammer out how this will work inside libraries.  If my app is using multiple libraries I need to know I have full control of how they log and where (), and if I write libraries I need to include logging that will not affect performance or added dependencies.

I like the idea of a standard interface for D logging.  Other logging implementations should be able to plug into the interface without having to inherit from std.log.Logger (single inheritance issue).

I would like to see conditional logging as part of the interface, or in the documentation show how we can achieve that with stdlib in a clean and simple way.

Logger should include a shared Logger, or include it in the interface for outside libraries to handle the implementation.  There will be libraries that thread internally and will need to support shared logging.



> 4) Any additional comments for author.

Awesome work so far. Getting this "right" is I huge pain, and I applaud you going through this.

> Awesome work so far. Getting this "right" is I huge pain, and I applaud
> you going through this.

I should have said this as well.  Regardless, I second this statement as this is probably the thing I'm looking forward to the most when it comes to additions to the standard library.

Yes for experimental.

On 7/28/14, 11:46 PM, Dicebot wrote:
> On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei Alexandrescu wrote:
>> No in current form. Yes assuming the fixes below are implemented.
>
>> ...
>
>> No. I also think any new module should sit in std.experimental for one
>> release cycle.
>
> Clarification, just to be sure you got it right - right now we _only_
> vote on inclusion into std.experimental, even if majority of voters will
> consider it Phobos-quality. Staging period of one release cycle is
> mandatory.
>
> That said - can you explain a bit more why you think it can't be
> included in std.experimental? (== think that it is fundamentally broken
> to the point it can't be even suggested for experiments) Most issues
> listed seem to be more related to actual Phobos inclusion.

I explained in the non-negotiable points. The point of keeping a module in std.experimental is watching for only minor tweaks. I think e.g. the names in the API is in need of solid change, which is easy to effect but affects callers quite a bit. -- Andrei

On 7/29/14, 5:23 AM, Dicebot wrote:
> On Tuesday, 29 July 2014 at 12:18:31 UTC, Robert burner Schadek wrote:
>> maybe we should have made a vote for logc vs. log(bool) first
>>
>> I think we gone full circle ulong.max times by now  ;-)
>
> This shouldn't affect inclusion to std.experimental and can be done at
> any moment

NO.

We put something in std.experimental when we can't imagine what other work is to be done on the module. (Inevitably a little more work is prompted by usage, which is the point of it all.) We don't put in std.experimental stuff that has already a known backlog of work to do.


Andrei

On 7/29/14, 5:18 AM, Robert burner Schadek wrote:
> maybe we should have made a vote for logc vs. log(bool) first
>
> I think we gone full circle ulong.max times by now  ;-)

My understanding is the entire prefix-letter approach was based on an oversight.

Andrei

On Tuesday, 29 July 2014 at 16:59:51 UTC, Andrei Alexandrescu wrote:
> The point of keeping a module in std.experimental is watching for only minor tweaks.

I agree. For this reason, I also vote for "no" (1 as well as 2), as the current conditional logging support doubles the size of the API for shaving a grand total of 3 characters off the invocation in a rather infrequent use case.

Cheers,
David

On 7/29/14, 10:16 AM, Andrei Alexandrescu wrote:
> On 7/29/14, 5:18 AM, Robert burner Schadek wrote:
>> maybe we should have made a vote for logc vs. log(bool) first
>>
>> I think we gone full circle ulong.max times by now  ;-)
>
> My understanding is the entire prefix-letter approach was based on an
> oversight.
>
> Andrei

s/prefix/suffix/