New syntax proposal: Conditional matching

[brendanzab]

Currently if you want to match only on conditionals you have to use a pointless expression at the beginning of the match and use _ at the beginning of each line.

match x {
    _ if x >= 0 => x / y,
    _ if y >  0 => ((x + 1) / y) - 1,
    _           => ((x + 1) / y) + 1,
}

I have also noticed this used out on a blog post (under the heading First version…).

Yes, you could always use if/else, but it's ugly in some use cases.

if x >= 0 { x / y }
else if y > 0 { ((x + 1) / y) - 1 }
else { ((x + 1) / y) + 1 }

// with formatting
if x >= 0 {
    x / y
} else if y >  0 {
    ((x + 1) / y) - 1
} else {
    ((x + 1) / y) + 1
}

// or maybe:
if      x >= 0 { x / y }
else if y >  0 { ((x + 1) / y) - 1 }
else           { ((x + 1) / y) + 1 }

What if when you leave out the expression at the beginning of the match you could only match on conditionals? This would be equivalent to Scheme's cond.

match {
    if x >= 0 => x / y,
    if y >  0 => ((x + 1) / y) - 1,
    _         => ((x + 1) / y) + 1,
}

Maybe you could even get rid of the ifs and just take boolean expressions, although I think it sacrifices some readability.

match {
    x >= 0 => x / y,
    y >  0 => ((x + 1) / y) - 1,
    _      => ((x + 1) / y) + 1,
}

[jdm]

I think the last one is confusing if you combine it with identifiers:

match x {
  x == 0 => x,
  x => y
}

[graydon]

I'd be relatively ok with making a leading if imply a missing _ pattern, assuming it's not syntactically ambiguous (I don't think it is).

I agree with @jdm that removing the if makes it too likely to cause visual confusion between patterns and expressions.

[brendanzab]

@jdm you'd still have to use _s normally. The syntax would only be used when the leading expression was left out.

match x {
  _ if x == 0 => x,
  x => y
}

match {
  x == 0 => x,
  _ => y
}

But as I stated above, I'm not really as much of a fan of the second syntax

[brendanzab]

@graydon would you be able to leave out the beginning expression on the match? ie. match <expr> { ... }? or maybe you could at least allow match _ { ... } (this doesn't work currently)

[bstrie]

As much as I hate to say it, it seems like this is an occasion where one should really be reaching for if rather than match. Could this also be done with a macro?

[graydon]

Yeah, a cond macro might work just as well

[brendanzab]

cond!(
    if x >= 0 => x / y,
    if y >  0 => { ((x + 1) / y) - 1 }
    _         => ((x + 1) / y) + 1,
)

Might see if I can figure something out.

[brendanzab]

Macro!

macro_rules! cond(
    ( $(if $pred:expr $body:block )+ else $default:block ) => (
        $(if $pred $body else)+
        $default
    )
)

fn main() {
    let x = 1;
    cond!(
        if x < 0 { io::println(~"woops");   }
        if true  { io::println(~"hullo");   }
        else     { io::println(~"bananas"); }
    )
}

[nikomatsakis]

Shall we close then?

[nikomatsakis]

Also: with respect to bjz's comment about omitting the expression in a match, if you just want a dummy value, then I would suggest the () expression:

match () {
    _ if foo => { ... }
}

which doesn't seem especially onerous. (This doesn't address the question of removing the _ pattern, of course)

[brendanzab]

Is this something that you'd be ok with adding to syntax::ext::expand? This is what I have at the moment:

//
// A Scheme-style conditional that helps to improve code clarity in some instances when
// the `if`, `else if`, and `else` keywords obscure predicates undesirably.
//
// # Example
//
// ~~~
// let clamped =
//     if x > mx { mx }
//     else if x < mn { mn }
//     else { x };
// ~~~
//
// Using `cond!`, the above could be written as:
//
// ~~~
// let clamped = cond!(
//     | x > mx { mx }
//     | x < mn { mn }
//     _        { x  }
// );
// ~~~
//
// The optional default case is denoted by `_`.
//
macro_rules! cond (
    ($( | $pred:expr $body:block)+ _ $default:block ) => (
        $(if $pred $body else)+
        $default
    );
    // for if the default case was ommitted
    ( $( | $pred:expr $body:block )+ ) => (
        $(if $pred $body)else+
    );
)

I used the | and _ symbols because I found using if and else was a little confusing. I also removed the => because it could be also be confusing (as @jdm said).

Here's an example of how it could be used in std::fun_treemap:

/// Insert a value into the map
pub fn insert<K:Copy + Eq + Ord,V:Copy>(m: Treemap<K, V>, k: K, v: V) -> Treemap<K, V> {
    @match m {
        @Empty => Node(@k, @v, @Empty, @Empty),
        @Node(@copy kk, vv, left, right) => cond!(
            | k <  kk { Node(@kk, vv, insert(left, k, v), right) }
            | k == kk { Node(@kk, @v, left, right)               }
            _         { Node(@kk, vv, left, insert(right, k, v)) }
        )
    }
}

/// Find a value based on the key
pub fn find<K:Eq + Ord,V:Copy>(m: Treemap<K, V>, k: K) -> Option<V> {
    match *m {
        Empty => None,
        Node(@ref kk, @copy v, left, right) => cond!(
            | k == *kk { Some(v)        }
            | k <  *kk { find(left, k)  }
            _          { find(right, k) }
        )
    }
}

I'm sure there are more instances beyond std where this could be used.

[brendanzab]

@nikomatsakis brought up on IRC that not having this is kinda sad when you're stacking ORs: cond!(| x == 3 | y == 4 {}). But it'd be ambiguous, as pred is an expr. We could use || instead which also plays nicely with &&, but then it'd make stacking with the underscore trickier. Hmm...

[brendanzab]

Woops, hit the wrong button :S