LogLocation lifetimes.

[dpc]

Could LogLocation::module_path() and LogLocation::file return 'static str, since they own them as &'static str? I am actually hitting this, and I need to use hidden variables directly instead.

[sfackler]

I think extending these lifetimes would be fine - thoughts @alexcrichton?

[alexcrichton]

It may make it harder to dynamically generate these records in the future, but I'm not sure if there's even a case for that?

[dpc]

LogLocation expects &'static str to be created, so... either LogLocation becomes LogLocation<'a> and takes &'a str, or LogLocation::module_path() can always return &'static str.

[dpc]

Actually. Is there any reason why LogLocation couldn't be LogLocation<'a> and hold &'a str only? Even though obviously function! etc. will always be 'static I can already see that accepting &'a would give more flexibility.

The drawback is, that logging backend would not be able to save the &'static str directly (but it can clone if has to). Considering that accessors functions return &'a str noone is depending on it.

[stephaneyfx]

I would like to suggest a different idea. As mentioned in this other post, an important use case is integrating a foreign logging system, so that messages from this system (e.g. a C library) can be forwarded to the Rust logger. The location of such foreign log messages is not necessarily a static string, or may not even be in UTF-8, requiring a dynamic conversion. To accommodate for this, wouldn't it be better to define Location as follows?

pub struct Location {
    pub __module_path: Cow<'static, str>,
    pub __file: Cow<'static, str>,
    pub __line: u32,
}

This avoids the cost of dynamic allocation for logging originating from Rust code while allowing locations not defined statically (e.g. because they come from a C library). One potential drawback is that Location is not Copy anymore.

Of course the use case of integrating a foreign logging system depends on #95 to define a LogBuilder or some other API to officially allow user code to create Location instances and pass them to the logger.

[whitequark]

This would be great but unfortunately there is no Cow with #![no_std], unless you opt into liballoc.

[stephaneyfx]

Thank you. I opened #206 to track the integration with foreign loggers and the no_std issue is mentioned in #206 (comment).