Should there be a record_static_str method in the Visit trait for static string optimization?

[lalitb]

I’m new here and not familiar with the codebase, so this is more of a question than a suggestion. I was wondering if it would make sense to have a record_static_str method in the Visit trait for handling static strings. The goal would be to allow optimizations for static strings and avoid unnecessary allocations for those cases where it might be beneficial.

Something like:

fn record_static_str(&mut self, field: &Field, value: &'static str) {
    self.record_str(field, value);
}

This could default to record_str for backward compatibility, but it might allow implementations to (micro)optimize for static strings and avoid allocations.

Sorry if I am missing something basic, and there are reasons why static and non-static strings don’t need to (or can't) be differentiated in this context?

[kaffarell]

Hmm do you have an example impl that doesn't allocate on a &'static str and does on &str? In this codebase, most of the implementations of record_str do not seem to allocate anything, they mostly just write! the value directly.

[lalitb]

@kaffarell an example here -
https://github.com/microsoft/rust_win_etw/blob/24b50ad6d557cbb3647d3d261f1c331700f96c4d/win_etw_tracing/src/lib.rs#L343

The record_str implementation has to create a owned String to be used outside the scope of this method, irrespective of the fact that event macro may have been called with &'static str as input for this argument.

[kaffarell]

Oh, I see the use case. Sure, this wouldn't be too bad, it won't even be breaking change AFAICT.