Builder syntax

[Soni]

you've heard of builder pattern, but... let's say you have

let x = Foo::new();
x.thing(foo);
x.thing(bar);
x.thing(zed);

actually for better effect let's say you have

let x = { let mut temp = HashMap::new();
temp.insert("foo", "bar");
temp.insert("baz", "zed");
temp };

now, hashmaps are clearly not builders; but what if they could be used as if they were? we'd like to propose the following syntax:

let x = HashMap::new()(.insert("foo", "bar"))(.insert("baz", "zed"));

as exact sugar for the following:

let x = {
  let mut temp = {
    let mut temp = HashMap::new();
    temp.insert("foo", "bar");
    temp
  };
  temp.insert("baz", "zed");
  temp
};

this is actually pretty easy to parse as the token for this is really (. and not some arbitrary thing. but anyway. thoughts? this would also provide ergonomics for using certain types of iterators (but we don't have a good example for that).

[ibraheemdev]

Hmmm... this

HashMap::new()(.insert("foo", "bar"))(.insert("baz", "zed"));

looks pretty weird to me personally. If a type is commonly built like this, why not just have a builder?

[eminence]

What about borrowing inspiration from the vec! macro and creating a new hashmap! macro that might look something like:

let map = hashmap![
    "foo": "bar",
    "baz": "zed"
];

(Actually, I'm about 90% sure I've seen this macro before, but I can't remember where)

[ibraheemdev]

maplit provides a couple macros for building collections:

let map = maplit::hashmap!{
    "a" => 1,
    "b" => 2,
};

I agree there should be hashmap macro in std.

[Soni]

We took inspiration from our own query language here. Our query language doesn't really have variables, instead you're supposed to use these things that run a query on the current value but leave said value for the next part to query again.

It means you can have something like

->'projects':$dict
  ->commit[:?$str:?$commit]:?$dict
    ->url[:?$str:?$uri]:?$dict
      ->branch:?$dict
        (->active'active'?:?$bool)
        (->federate'federate'?:?$bool)?

and extract both "active" and "federate" in one go.

While it's only a query language, the syntax elements do have the following properties:

1. They can have side effects
2. They can accept a value
3. They can return a value

Which means they're all basically functions! But sometimes you want to apply side effects but the return value is useless to you, and that's the exact use-case this syntax solves.

[eko]

Are you proposing a new expr(.expr) syntax for consecutively calling methods? I don't see any need for a such syntax, your hashmap example is already solvable by macros as other said. Can you give better examples about why this can be usefull and worths introducing a new syntax?

[RustyYato]

This is a well trodden problem: It even has an implementation as a crate https://crates.io/crates/cascade

Previous motivations:

Why does `Vec::push` not return a mutable reference to itself?

Can we have this API? impl<T> Vec<T> { pub fn push(&mut self, value: T) -> &mut Self; } So we can allow the following pattern: pub fn foo() -> Vec<char> { Vec::new().push('f').push('o').push('o') }

Previous discussions:

Method-cascading and pipe-forward operators proposal

In this topic I want to draw attention, show purpose and share initial idea about syntax for them. Before reading, note: I’m just an enthusiast - don’t take that too seriously and don’t be too critical if something wrong; prepare to bad English. Jump to second version - text below is not actual It consists of two parts because in my proposal both are related and second can be combined with first to cover additional use case. Also, both have different syntax from one that may be found in ot…

Method chaining special form

A few methods have slipped in that, as far as I can tell, are just to make method chaining more convenient. In particular, Vec.append_one is just a push that returns self afterwards. Rather than bloat up the API with lots of similar-but-subtly-different methods, I’d prefer if this pattern were generalized to something reusable. Ruby has tap for exactly this, and tap could be implemented pretty easily in Rust, though it’s exceptionally verbose: //Stolen from kimundi trait Tap {     fn tap(mut…

[Soni]

yeah you can use ? in it. e.g. with a hypothetical slice iterator with a split method that splits the slice at the current iterator position, you could do something like iter(.next()?).split(). since arbitrary iterators aren't really splittable, this solves it quite easily! (altho perhaps not cleanly?) (and, if instead you wanted to make arbitrary iterators splittable, like say iter.skip(1).split()... how would you implement something like that?)

[comex]

Prior art: Dart's method cascade syntax.