Add spawn! and try! macros

[bytbox]

Once #11868 is through, I think this (partially suggested by @brson) is a good idea.

[alexcrichton]

I think another thing would that would make this even cooler would be to allow braces on expression macros. Then you could do this:

spawn! {
    // do some computation
}

Whereas today you're forced to use parentheses.

[brson]

Yeah, we really need to allow braces here. I'm not sure why we can't. @paulstansifer, @jbclements

[brson]

I'd suggest holding off on try! though. spawn! is very common so it would be nice to sugarize it, but try is not all that common.

[thestinger]

I'm worried about adding a special-cased macro for something like this, as there are no doubt many other functions that are going to take a single procedure as a parameter. It isn't something you should have to do every time for nice syntax.

[paulstansifer]

@brson Is the idea that the invoker would be able to chose whether to use {} or (), and the macro itself would never find out? I think that'd be a simple change to make in two or three places in the parser.

We briefly had macros always take {}, but then migrated to (). There's no reason we can't have both.

[brson]

@paulstansifer yes, that's what I was thinking

[sfackler]

Why is the {} thing an issue? Macro-rules style macros can use {} in addition to () already (e.g. condition!).

[huonw]

@sfackler only in an item context; can't do it in an expression context (e.g. println! { "" } is a parse error).

[brson]

@thestinger maybe we can create a macro that creates macros like spawn! from function names: macroize!(std::task::spawn).

[jbclements]

@paulstansifer there are no parse ambiguities for curlies? sounds good to me...

[paulstansifer]

No ambiguities. The ! is distinctive (although I wonder what kind of
trouble type-position macro invocations might cause).

[wycats]

@brson the point of try! is to make it more common. Today, one of the major reasons not to use Result is that it's really awkward to use.

The try! macro makes it a lot easier to use a bunch of Results in a single function:

// uses fictitious IO APIs as an example
fn readlines(filename: &str) -> Result<~[~str], IoError> {
  let file = try!(files::open(filename));
  let body = try!(file.read());
  body.split('\n').collect()
}

This makes it easy to linearize a bunch of calls to functions that return results without introducing extra levels of indentation or adding limitations to interspersed code.

While try! itself is not very common (by definition), a desire to forward on Err() (as opposed to unwrapping and triggering a full-on fail) is very common. The ergonomic difficulty of doing so is one of the reasons people don't like to use Result.

[brson]

@wycats That is not what I thought the try! macro was for - I assumed it was for the task::try function. Your use case is something we should have a macro for.

[brson]

Oh, but since task::try returns a result your try! macro should work for it equally. I was worried about having two things called try but they are pretty similar. For trying something in a task though you would end up writing

let foo = try!(try(proc { ... }));

[brson]

A try! that sees proc as its first token could spawn it into another task automatically.

[sfackler]

That seems like it'd be a bit confusing. Wasn't the early return macro called if_ok! or did it get renamed?

[wycats]

@brson ah. I got confused because of #11754 which I saw that you reviewed 😄

[wycats]

@sfackler I'm not too hung up on the name, but I think it's a good thing to avoid multi-word underscored names for commonly used language features. In my ideal world, macros wouldn't require parens and the above code would look like:

// uses fictitious IO APIs as an example
fn readlines(filename: &str) -> Result<~[~str], IoError> {
  let file = try! files::open(filename);
  let body = try! file.read();
  body.split('\n').collect()
}

[japaric]

What's left to be done here?

• Macros accept curly braces
• We have a try! macro
• spawn is in the prelude

[reem]

I think the goal was to make spawn not require writing out the proc(), but it seems that conventions have changed and a spawn macro is not really appropriate or needed anymore.

[reem]

This can probably be closed at this point, since this would only save 2 characters over unboxed closures.

[steveklabnik]

Agreed.