Thank you for engaging with the substance. Such things are heuristics, but in my experience and opinion there is very rarely a reason to pass `const std::string&` (or it's close cousin `const std::vector<SomeTypeT>`) in modern C++, the passing semantics that are good defaults are 1. `std::string` as value if the callee needs the value (sometimes you might take `std::string&&`, doesn't buy you much though as `std::string` has an rvalue constructor that will do the right thing) or 2. `std::string_view` (or it's close cousin `std::range<SomeTypeT>`) if you only need a view of it. This has the nice property that pass by value will usually fit in registers (if the call isn't inlined entirely, either way you're on the stack and often the cache line), and that it will go out of scope while the backing region is still valid, it's hard to get wrong. Those should often but not always be `const`, sometimes it's handy to have a `std::string_view` already on the stack if you're going to slice some prefix off it or something.

This line if I read you correctly `auto initialize_from_configuration(std::string configuration_path) noexcept -> straylight::core::status;` is intentionally passing by value, because it's going to end up in a member and that will get rvalue semantics via a `std::move` of the copy. Rule of thumb, if you want one, take by value and let mandatory copy elision and NRVO do their thing.

Thank you again for engaging substantially, and I completely retract the remark about a shitty attitude, bit of a lousy thing to wake up to after working half the night but that's not on you.