Guide: if

[steveklabnik]

Adding the section about if to the guide. I hope this won't conflict with #15229 , but we'll just have to see, I guess.

[Ryman]

The code above is missing the type annotation which this refers to?

[steveklabnik]

Whoops! Fixed in c7638ea, thanks!

[pfalabella]

Not sure if it makes sense to mention somewhere that actually any block of code surrounded by {} is an expression. I.e. you could do this:

    let a = {
        let a_string = "calculating a...";
        println!("{}", a_string);
        let a_len=a_string.len();
        a_len
    };

[steveklabnik]

@pfalabella I do think it'd be good to mention it, though I wonder if this would make sense after I explain functions. That looks very similar to

let a = foo();

// elsewhere

fn foo() {
    // what you wrote
}

[pfalabella]

@steveklabnik to me (but very possibly just to me...) it's easier to remember just that any block is an expression, as it helps me parse what happens in ifs, matches and yes, functions.
i.e.

let a = {println!("assigning"); 42u } // this is rarely useful

// but logically it's the same thing that happens here 
let a = if something {println!("assigning"); 42u } else {6u}

// and here
let a = match something {
   1..10 => {println!("assigning"); 42u }
   _ => 1
}

// and here
fn gimme_the_answer() -> uint {println!("assigning"); 42u }

[steveklabnik]

Right. But we haven't talked at all about functions and match yet. I would love to show exactly that, but we can't do it here, we have to do it later.

[pfalabella]

@steveklabnik I mean that the first concept (again, for me...) is foundational to understanding the others more easily, as they are all, in a way, a logical generalization. So if you want to mention it, it might make sense to mention it before all the others.
But I won't get offended if you decide the guide flows better without it (great job, by the way!!).

[Sawyer47]

C has NULL macro, C++ has also nullptr. But is it necessary to mention about null here? I would rather expect better explanation what () is and what it has to do with semicolons. The fact that () is both name of a type and the only value of that type might be confusing for someone who doesn't know rust so it definitively needs good explanation.

[steveklabnik]

Sometimes, people call () 'nil', hence me explaining it here.

That said, you're right, I can probably expand this a bit. I didn't explicitly say that ; produces the ().

[steveklabnik]

Fixed.

[pnkfelix]

@steveklabnik okay, looks good to me apart from my nit noted above on the one sentence about assignment being an expression in Ruby.

[pnkfelix]

consider adding a comment saying that this is erroneous code.

i get this from the current rustc:

let x = (let y = 5); // error: found `let` in ident position

but I guess if we put that error output into the example, we'll need one more sentence explaining "The compiler is telling us here that it was expecting to see the beginning of an expression, and a let can only begin a statement, not an expression."

[steveklabnik]

Sigh. In my rebase I lost a small change, it seems. I have triple-checked that rustdoc doesn't give any errors on my machine. r? @pnkfelix

[steveklabnik]

Sigh. One more time.

[pnkfelix]

You need to put the ignore markers here, I think. At least i think this is the source of the current Travis failure.

[steveklabnik]

What I'm currently wondering is: why does my Rustdoc not complain?