Enjoyed this post! I think you've missed out the most basic one though, which is to declare every field as`pub` and use the raw struct syntax to make new objects. Especially for simple parameter list structs which implement Default, I much prefer to skip the builder pattern and use
```
Struct {
field1: "value",
field2: 3224,
field3: Enum::Variant,
..Default::default()
}
```
You miss out on encapsulation etc but for simple cases where it's clear you don't need it, this is super low maintenance
Haha you’re totally right. I went off cataloging all the “fancy” constructor patterns and forgot the most obvious one: just make the fields pub and use struct literal syntax. That’s about as Rust as it gets.
That’s the trap of trying to write a “comprehensive” post. I get so caught up in the official or idiomatic stuff that I forget the dead simple low-maintenance approach most of us actually use every day. Appreciate you pointing that out, I’m laughing at myself here.
Great post! Something else I'll mention is that I often find myself implementing another constructor-like pattern across multiple codebases I work on, which is something like
```trait Arbitrary { fn random() -> Self; }```
Great for testing purposes, typically. I'd love for this to come with standard library, but I figure they opted against it because it **almost** implies a dependency on `rand` or some other source of entropy. But I feel a little bad every time I define this trait thinking there must be A Better Way.
Thanks, totally on the same page here. I build the same trait all the time because random input in tests is way more convenient. But I think that’s exactly why it doesn’t live in the standard library. It’s a testing-specific need and the standard library stays general-purpose and avoids picking RNGs/seed policies/adding a rand dependency. Have you tried proptest or quickcheck yet? They give you the same random constructor behavior without reinventing it each time, plus features like shrinking and nicer ergonomics.
I gave quickcheck a quicklook, but decided against adding another crate when all that I really needed was a single-fn trait definition. But maybe I’ll give it another look, I never considered what other features it might offer.
Great article!
`From` for infallible conversions and `TryFrom` for fallible ones.
PS: Oh, I just needed to read on.
Enjoyed this post! I think you've missed out the most basic one though, which is to declare every field as`pub` and use the raw struct syntax to make new objects. Especially for simple parameter list structs which implement Default, I much prefer to skip the builder pattern and use
```
Struct {
field1: "value",
field2: 3224,
field3: Enum::Variant,
..Default::default()
}
```
You miss out on encapsulation etc but for simple cases where it's clear you don't need it, this is super low maintenance
Haha you’re totally right. I went off cataloging all the “fancy” constructor patterns and forgot the most obvious one: just make the fields pub and use struct literal syntax. That’s about as Rust as it gets.
That’s the trap of trying to write a “comprehensive” post. I get so caught up in the official or idiomatic stuff that I forget the dead simple low-maintenance approach most of us actually use every day. Appreciate you pointing that out, I’m laughing at myself here.
Great post! Something else I'll mention is that I often find myself implementing another constructor-like pattern across multiple codebases I work on, which is something like
```trait Arbitrary { fn random() -> Self; }```
Great for testing purposes, typically. I'd love for this to come with standard library, but I figure they opted against it because it **almost** implies a dependency on `rand` or some other source of entropy. But I feel a little bad every time I define this trait thinking there must be A Better Way.
Thanks, totally on the same page here. I build the same trait all the time because random input in tests is way more convenient. But I think that’s exactly why it doesn’t live in the standard library. It’s a testing-specific need and the standard library stays general-purpose and avoids picking RNGs/seed policies/adding a rand dependency. Have you tried proptest or quickcheck yet? They give you the same random constructor behavior without reinventing it each time, plus features like shrinking and nicer ergonomics.
I gave quickcheck a quicklook, but decided against adding another crate when all that I really needed was a single-fn trait definition. But maybe I’ll give it another look, I never considered what other features it might offer.