Good grief - and I thought Java had bad boilerplate. I feel that if these are the features you require of a language, maybe Rust is not what you should be using? There is a reason the language keeps it simple and writing stuff like this, though convenient once or twice (when coding), goes against why I'd pick Rust (hard to beat performance).
Builder Pattern in Rust
91–93 of 93 posts
Re: Builder Pattern in Rust
#92Earlier quoted context omitted.
At the risk of being pedantic, I would use separate types there for the id's to avoid this kind of issue, but in general I agree with your point
What would you do about a slice function? Without the parameter names you won't even see if the second parameter is length of the slice or its right end.
In C# (prior to C# 8.0) without parameter names you would get an ambiguous overload error (and overload resolution is strictly by types, not by names - except for extension-methods). C# 8.0 side-stepped this problem by adding an explicit range operator.
However I feel the best approach is to have first-class language support for parameter-arguments-to-type homomorphisms (e.g. `TArgs args = new( arg1, arg2, arg3 ); YourMethod( args );`).
Re: Builder Pattern in Rust
#93Earlier quoted context omitted.
Unfortunately hardly any ORMs support that (especially not EF, argh), and writing custom value-types is a painful experience given C# (still) doesn't support strict typedefs nor mixins.
If only structs were inheritable, then you could roll your own `struct Wrapper ` with operators for implicit conversion, equality, etc, and then extend it with just the name and type. Wouldn't help with the EF pain point though, and I'm sure it might confuse newcomers initially.
Inheritance shouldn't be abused to make-up for the lack of true mixins, though.