July 29, 2014
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
July 29, 2014
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.
July 29, 2014
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.
July 29, 2014
> 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.
July 29, 2014
Yes for experimental.

July 29, 2014
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

July 29, 2014
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

July 29, 2014
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

July 29, 2014
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

July 29, 2014
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/

1 2 3 4 5 6 7 8 9 10 11 12