Getters

[killercup]

I wrote in #4 (comment):

I really want this to generate idiomatic Rust, so getters names would be prefixed with get_, e.g. get_foo() and get_foo_bar().

If I read rust-lang/rust#29599 correctly, it's not possible to generate ident on stable. If we were to do getters on nightly only, interpolate_idents might be helpful (usage example).

A more creative solution for stable might be creating a single get(&self) -> new_sub_module::Getter method, where Getter is a newtype that implements methods to get each of the struct fields, so you can do x.get().foo().

[nielsle]

It would be great to have a solution that allowed the user to use the builder as something like a rust-typemap. (Yes I know it is out of scope, but it would be great to have.). I tried to propose something similar over here

DanielKeep/rust-custom-derive#19

[colin-kiegel]

@nielsle thx for your suggestion. But I don't see that in this crate, because it's a different use case with different requirements.

But feel free to create a fork of derive_builder and replace https://github.com/colin-kiegel/rust-derive-builder/blob/master/src/derive_builder.rs#L47 and https://github.com/colin-kiegel/rust-derive-builder/blob/master/src/derive_builder.rs#L80

[colin-kiegel]

as long as we can't make this idiomatic, I would rate a workaround with low priority. It is already possible to make the fields public, which seems good enough as a workaround.

[colin-kiegel]

If a field is unset but has a default value, should the getter return None or the default value?

Note: Default values can be arbitrary functions with side-effects.

[TedDriggs]

@colin-kiegel I was thinking about that as part of the work on #85. As shown in the sample code in #79, I'd like to expose at least private getters with the signature get_foo(&self) -> Result<T, String>, which returns the explicit value of foo, the default value of foo(which may require invoking the default at the struct level), or an uninitialized field error. These private getters would make writing a validator function and/or custom build function much cleaner.

The downside seems to be that they require doing one of the following:

1. Take &mut self so that they can cache the default value after computing it once. Using them in conjunction with the validator hook would mean the validator had to take &mut self, and that would require changing the signature of the build method.
2. Cache the default value, but use a Cell to avoid calling the default methods more than once. This field would have to be private, which is a breaking change if anyone is depending on struct update syntax without a trailing .. clause.
3. Eagerly compute default values in FooBuilder::default() and prepopulate the fields with the values. This would interfere with any attempt at a set-once model.

[colin-kiegel]

What about this use case, where someone wants to query the builder whether a field is already set? If we don't include computing the default value, then we could allow this via get_foo(&self) -> Option<T>. It seems like we can't have both.

If we decide to include computing custom defaults, we could also

0. Accept that calling get_foo(&self) can be expensive, when custom defaults are defined.

[TedDriggs]

The "is set" case can be checked by querying the field directly, especially if the author is writing a custom build function or a validator.