Attempt number two/three? Too many in any case.
Previously I proposed a design that followed a `struct` like syntax:
```rust
info!("my message: {}", arg, {
key1: "value1",
key2: 123,
});
```
However it turns out that this does not work well with named arguments
as reported in issues #369 and #372. The implementation was eventually
reverted in pr #374.
This new design takes inspiration from the `tracing` crate which already
supports key-value pairs in logging events. The basic idea is to put the
key-value pairs before the message and arguments. Applying the same
structure like syntax as above we would get something like the
following.
```rust
info!({
key1: "value1",
key2: 123,
}, "my message: {}", arg);
```
But personally I'm not a big fan of this formatting, let's try putting
everything on a single line instead.
```rust
info!({ key1: "value1", key2: 123 }, "my message: {}", arg);
```
A little better, but at this point the structure like syntax is really
more annoying then helpful. So, instead I've done away it, opting
instead use the following syntax.
```rust
info!(key1 = "value1", key2 = 123, "my message: {}", arg);
```
Two major differences:
* Removed the brackets.
* Colons (`:`) are replaced with equal/assignment signs (`=`).
This gives us syntax similar to variable assignment.
But then we run in some limitations of the macro syntax, specifically
that `expr` fragments aren't allowed after `expr` fragments. To fix this
I went with the easiest option of changing the last comma (`,`) after
the key-value pairs to a semicolon (`;`). Making the final syntax look
like the following.
```rust
info!(key1 = "value1", key2 = 123; "my message: {}", arg);
info!(target: "my_target", key1 = "value1", key2 = 123; "my message: {}", arg);
log!(target: "my_target", log::Level::Info, key1 = "value1", key2 = 123; "my message: {}", arg);
```
Which, in my opinion and all things considered, it's too bad looking.
try_set_logger_raw is now set_logger and try_set_logger is now
set_boxed_logger. The use_std feature is now disabled by default. The
old set_logger has been removed.
When we did the crate evaluation for log, we wanted to add more variants
of set_logger that e.g. panicked by default, but I'm no longer convinced
that's a good idea. There are going to be very few instances of actually
calling these methods explicitly, since each logger implementation
should be providing their own init method that calls them. Having a huge
constellation of functions that all do basically the same thing just
makes things really confusing. We also don't want to encourage logger
implementations to only provide an init function that panics because a
common way of working with logging in tests is to try to init the system
in each test and ignore the result.
We may want to add things to the information provided to `log` and
`enabled`. slf4j provides the ability to pass `Marker` objects when
logging which can be used for more advanced filtering for example.
