• snaggen@programming.devOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    But the author doesn’t mention the most common way to pass named argument, so I include a comment from mjec over at lobster.rs that covers that (since I’m to lazy to write my own):

    It’s not obvious to me why the author didn’t include direct instantiation of the struct, rather than a builder:

    #[derive(Default)]
    struct SearchOptions {
       pub include_inactive: bool,
       pub age_within: Option<(u32, u32)>,
       // ...
    }
    
    let result = search_users(
     users,
     SearchOptions {
       include_inactive: true,
       age_within: Some((5, 29)),
       ..Default::default()
     }
    );
    

    This avoids the need for boilerplate enums, or to filter through a vec in order to find the value of an argument. Every caller has to specify …Default::default() but I don’t mind that! I like the idea that you have to explicitly acknowledge that you want everything else to be default values (and it might be useful to omit it in some places, so you get a compile error if new options are introduced).

    • DolceTriade@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      ya, maybe it’s the author’s ruby background? For example, in languages like go and C, using structs for optional arguments is basically the norm.

  • thicket@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Does anybody have insight into the design choice away from named arguments? Everything in the article and in the comments seems like different levels of kludge around an unfortunate decision