Right, I want the convenience of &[&str] , but if it requires creating a second collection then I think &[String] is better. Use cases that require &str can just map to as_str.

Thanks for the feedback.

• I’ll definitely drop the Cypher prefix, and think it’s a good idea to at least move the shorthand attribute macros to a crate feature. The readmes would use derive instead of the shorthand mostly.
• ty::new() just uses the types in the struct (plus &str for String and &[T] for Vec). The extra builder struct is to help with updates, where you may want to just change a couple of fields, or bind it to editable UI fields.

I didn’t realize how strong the rust presence is here. Experienced-devs on reddit is hard to go without :)

Must have forgot to write it down

I’m not. How bad was it?

That’s the one problem. An LLM enhanced terminal sounds great. Sharing every command with the cloud does not.

I’ve had that article saved for years, it’s still the best way to break down documentation imo.

Another key point for code documentation is that the closer it is to the code it’s describing, the more likely it is to be read and maintained. The book “A philosophy of software design” has a section on it.