Add `emit_bytes` method.

[Kixunil]

When tracing it's often useful to log various internal bytes such as messages being communicated. This adds emit_bytes method to make this easier and to possibly keep the type information.

Before I go on and work on this more, what do you think about adding this?

Make sure to:

• [ ] Add an entry to CHANGELOG.md (if neccessary)

[dpc]

I guess fine with me. :)

[Kixunil]

One more thing that came up recently, maybe it'd be useful to include some hint whether it makes more sense to show it as a byte stream or a single value (hash, public key, ... - see https://github.com/Kixunil/ln-types/blob/master/src/node_id.rs#L414-L420 )

Ideally it'd be #[non_exhaustive] enum but I think it's not supported by slogs MSRV. (Any plans on MSRV bump?) So maybe instead:

// will become non-exhaustive enum once MSRV is there.
struct BytesKind(BytesKindInner);

impl BytesKind {
    pub fn stream() -> Self { ... }
    pub fn value() -> Self { ... }
}

enum BytesKindInner {
    Stream,
    Value,
}

fn emit_bytes(&mut self, key: Key, bytes: &[u8], kind: BytesKind) -> Result { ... }

Or alternatively just emit_byte_stream, emit_byte_value

What do you think?

[dpc]

MSRV seems fine with me. I keep it artificially low, just to not bother people. Though I think two methods with a default implementation of one forwarding to the other would work well too.

[Kixunil]

Looking at it, non_exhaustive was stabilized in 1.40. That's almost as new as Debian oldstable. I will probably go with methods instead but I'd rather not forward one to the other but to emit_arguments with different formatting.

[dpc]

:+1:

[Techcable]

Looking at it, non_exhaustive was stabilized in 1.40. That's almost as new as Debian oldstable. I will probably go with methods instead but I'd rather not forward one to the other but to emit_arguments with different formatting.

I think we should say we add the BytesKind enum directly to the method without any wrappers.

There are two ways we can use #[non_exhaustive] but still avoid bumping the MSRV:

1. syn uses a__NonExhaustive variant which is #[doc(hidden)] (they also support 1.31 like we do)
2. We can use rustversion to use a proper #[non_exhaustive] attribute, but conditionally enable this on versions >= 1.40 😄

We could also do both, so the code would be

#[rustversion::attr(since(1.40), non_exhaustive)]
enum BytesKindInner {
    Stream,
    Value,
    #[doc(hidden)] // Used for 1.31 compat
    __Nonexhaustive
}

[Techcable]

Hi! I did three things here:

1. Merged branch master to update this PR
2. Added a BytesKind enum
3. Changed the default formatting

Old formatting for i32::to_le_bytes(-1) would be FF FF FF FF.

Notice the spaces 😦

New formatting depends on BytesKind

Kind	Example	Underscores	Prefix
BytesKind::Stream	0xFFFFFFFF	No	0x
BytesKind::Value	0xFFFF_FFFF	Yes (every 2 bytes or 4 chars)	0x
BytesKind::PlainValue	FFFFFFFF	No	None
old default	FF FF FF FF	Uses spaces Eevery bytes	None

The impls for Vec<u8> and [u8] are assumed to be Stream.

The BytesKind::default() is BytesKind::Value.

Also BytesKind uses a doc(hidden) __Nonexhaustive variant to avoid bumping MSRV. This is what syn used to do

I would appreciate your thoughts on this @dpc and @Kixunil

[dpc]

Looks reasonable.

[Techcable]

Manually merged in d9fddedfbca305d4905447412cd6272fefed9dde and fe3ad8a142ea3bd9268849a706e67b8967e6e4b7

Sorry for taking so long :)