That revision of the style guide is expressly written for consumption by agents, it says so in the introduction, so agents edit it whenever they fuck up in C++, that's on purpose.
Just about all the snippets are lightly adapted from shit I wrote before agents were relevant, so any fail in there is on me.
Do you have any errata or just a shitty attitude?
One man's attempt at a wry observation is another's shitty attitude, I suppose. It just struck me, as 2/3 of the target audiences mentioned are made up of people, and here is a doc that's been more than just breathed on by an LLM - and then we're to write config parsing by hand! The rationale is fine and all that, it just tickled me that here's an amusing example of having computers do people's work and having people do computers' work - playing (to my mind) to the strengths of neither.
(If the bots are allowed to modify the doc as they please, it's inevitable their writing style will seep in I suppose.)
If it'd be any consolation, the doc seemed fine, maybe even interesting, but the LLM writing style gives me a headache. I did notice a std::string by value that, according to the ref rules, could conceivably be a const std::string &, I think: https://gist.github.com/b7r6/5dde648f5dc1dea1e9039f2211f5d40... - whether this is worth caring about, given that it's apparently loading a file, I don't know, and there could be some other reason for this not evident in the code provided. (Or maybe I missed something, probably something obvious.)
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.