Allow any expression / statement in "if expressions"

[Anthony-Gaudino]

V version: 0.1.25 ab3f6d9

Currently using an if expression and trying, for example, to declare a variable inside it throws an error:

s := if true {
	a := 1
	a
} else {
	2
}

This results in:

error: expected expression before ‘int’
 6879 |  int s=int a= (( 1 ) ? ( 1 ,  a ) : ( 2 )) ;
      |        ^~~
V error: 
==================
C error. This should never happen.

I believe programmers would expect they could do anything they can in an if statement also in an if expression and the last expression in an if expression would be the value yield. So this for example should be allowed:

a := 2

s := if true {
	b := 1
	mut c := 0

	if a > b {
		c = 100
	} else {
		c = 200
	}

	c // Value yield
} else {
	c := if a == 2 {
		c = 100
	} else {
		c = 200
	}

	c // Value yield
}

OR

a := 2

s := if true {
	b := 1

	if a > b {
		100  // Possible value yield
	} else {
		200  // Possible value yield
	}
} else {
	if a == 2 {
		100  // Possible value yield
	} else {
		200  // Possible value yield
	}
}

---

Maybe a keyword like return could be used inside if expressions to make the return value more obvious:

a := 2

s := if true {
	b := 1

	if a > b {
		return 100
	} else {
		return 200
	}
} else {
	if a == 2 {
		return 100
	} else {
		return 200
	}
	
	// This would never be executed
	return 300
}

So if expressions would work more similar to a lambda / anonymous function.

To do the same in Javascript would require the more verbose:

const a = 1;

const s = ( () => {
    if (true) {
        const b = 1;

        if (a > b) {
            return 100
        } else {
            return 200
        }
    } else {
        if (a === 2) {
            return 100
        } else {
            return 200
        }

        // This would never be executed
        return 300
    }
})();

---

Rust supports it:

fn main() {
    let i = 5;

    let c = if i > 4 {
        let d = 5;
        d
    } else {
        6
    };

    println!("{:?}", c);  // 5
}

---

And last but not least, I believe that having a shorter if expression option with the same syntax as Python (Python ternary operator) would be very nice.

Python ternary operator has the form:

<expression 1> if <condition> else <expression 2>

Which is very friendly, slight more concise, allows chaining expressions and won't need adding another keyword like then to the language.

With it, this would be valid in V:

var := 100 if true else 200

This too would be valid:

var := if true { 100 } else { 200 }

---

Currently V transpiles if expressions to C ternary expressions, in these cases this should still be true:

var := 100 if true else 200  // Transpiles to: int var = 1 ? 100 : 200;

var := if true { 100 } else { 200 }  // Transpiles to: int var = 1 ? 100 : 200;

The Python if expression syntax, if implemented, wouldn't allow declaring variables as it wouldn't fit well with it's syntax.

In the case of declaring a variable inside an if expression:

s := if true {
	a := 1
	a
} else {
	2
}

it's not supported in C so it must be transpiled to something else, maybe a function.

[SleepyRoy]

I think this will complicate the language because when reading code of this style your brain must simultaneously deals with branches and locals/returns inside them.
Ternary itself IMO is already an information condensed operator so we'd better not further complicate it. It's friendly only for simple logics. If there're complex logics, I prefer if-else.

And about Python's ternary style. I code with Python, but I don't like it very much, because when reading ternary people natually want to first see the condition and next the branches. Consider this

var := aaaa+bbbb-cccc*dddd/(eeee*ffff)-gggg if abc && def && ghi else hhhh+iiii-jjjj

versus this

var := if abc && def && ghi { aaaa+bbbb-cccc*dddd/(eeee*ffff)-gggg } else { hhhh+iiii-jjjj } 

I have to say I perfer the latter, even though it's slightly longer.

If just for brevity, see C's style.

var := abc && def && ghi ? aaaa+bbbb-cccc*dddd/(eeee*ffff)-gggg : hhhh+iiii-jjjj  

I'm OK with this style. The downside is, exceeded brevity makes it sometimes difficult to find the separation of conditions and branches.

[medvednikov]

@Anthony-Gaudino this will be supported.