Closed FlixCoder closed 1 year ago
By the way, do you know of the darling
crate? It takes over the parsing of the attributes into structs and could make plenty of code here obsolete I think. The downside is of course another dependency.
Oh, maybe a note in the changelog is missing as well or do you maintain that yourself?
I don't mind updating the changelog myself, but I also wouldn't mind if you do that.
Well then feel free to merge unless there are more changes needed. I would try to remember the changelog as well in that case
Oh my god, I force pushed empty changes except the ones you suggested :( I am sorry
It's okay. They were very simple ones, and I was planning to do some modifications myself anyways.
I'm late to this discussion.
I think it'd be helpful if the new change is documented somewhere more discoverable.
@lebensterben How so? It's documented in the docs, like all other #[builder(...)]
-activated features (except default
, but without setting defaults there is little point in using the builder pattern in Rust so I do feel it deserves a place in the README). I'm not sure why build_method(into)
needs to be more discoverable than the rest of them?
@idanarye
sorry. I overlooked changes to the lib.rs
No problem. Sometimes it does take time for them to update...
I implemented both my suggestions in one from #52, so you can take a look how it would look like. It allows both, the generic output that the user decides the build output and the explicit output type. By default nothing changes.
When setting
#[builder(into)]
without a value, the user needs to specify a type when building and the output is automatically turned into the specific value. When setting#[builder(into = Type)]
, the build method returns that type instead of the original. The compiler complains accordingly when the type does not implementFrom<ActualType>
.I personally like the results :) Let me know what you think.