"This is an elegant use of Rust's trait system to separate construction from operation, with compile-time guarantees that the right capabilities are available when needed." - LLM

Except both me and my IDE are in the dark about what kind of object Foo::new(obj) *really* expects until I get the compile error?

(Foo::new() only prescribes EasyTrait, but Foo::bar() requires TrickyTrait)

#Rust

@buherator fwiw, I often rely on the compiler to tell me what it expected in places. For things that have trait bounds, it looks at the set of types that could fulfill the requirements and if it is a small list, it will mention them all. It's not perfect, but it works out ok when exploring new APIs.

@buherator I often see people about how rustc yells at them, and I find it more useful to approach it as having a conversation with it. Normally we ask "is this right?" but it can also be "what can go here?" or "who uses this?" (by removing code).

@ekuber Don't get me wrong, I'm positively amazed by rustc messages in general, and this one is no exception. On the other hand I also like to see how I should approach the API I'm about to use, having a map about the code base before I go down a path that just won't work. I feel like relying on the compiler is like periodically calling a hovering helicopter to get out of the woods, instead of having a proper $5 map.

@buherator one of my rule of thumb is that API docs have to have a code snippet showing representative usage, ideally exhaustive. But I'm glad I can rely on the tooling as a last resort if that's not available. This is also a consequence of the prevalent "right by construction" API philosophy that's prevalent in the Rust ecosystem: more complex checks are needed for that that can obscure the requirements.
Another under applied concept is checking not only how nice the API is when used correctly, but also how frustrating it is when used incorrectly (either by making things more opaque, or the diagnostics indecipherable).

@buherator when it comes to tool design, my philosophy could be described as "yes, and" 😄
Not everyone learns or works the same way, so the more approaches are explicitly supported in a sane way, the better.

@ekuber Having a chopper to call when you go hiking is definitely nice :D I don't quite get how the principles apply here though: in your opinion, for this particular example, would it be right to require all traits by ::new()?

@buherator I think its had to be prescriptive without looking at the context. I think it is OK to have something that is constructable with fewer restrictions and methods gated on the stronger restriction. But both the docs and the code should make things clear on how to get the more restricted initializer. This smels like the typed builder pattern where methods appear or disappear based on the type/const params.