Simplify constructor function

language design
36

I think most would agree that constructor functions don't need special syntax sugar, but some existing ideas just coincidentally resolve the issue raised by the post (A, B).

At the same time there are good reasons to have some kind of bracket elision in general. For example, imagine you have a large code block like:

match letter {
    Letter::A => println!("A"),
    Letter::B => println!("B"),
    Letter::C => println!("C"),
    // ..
    Letter::X => println!("X"),
    Letter::Y => println!("Y"),
    Letter::Z => println!("Z"),
}

and you want to apply a minor control-flow effect to that entire block. You'd have to find both ends of the block, wrap it in brackets, and preferably indent the contents.

It would be much more efficient if you could just prefix the block:

if can_print => match letter {
    Letter::A => println!("A"),
    Letter::B => println!("B"),
    Letter::C => println!("C"),
    // ..
    Letter::X => println!("X"),
    Letter::Y => println!("Y"),
    Letter::Z => println!("Z"),
}

After testing you might realize that this change doesn't work out, or it was just temporary from the start. Either way, reverting the change is just as easy (whereas reverting bracketing and indentation is tedious even with a decent editor in my experience). It's like the difference between function and method calls; there's a reason people use infix notation.

Now, it's arguable whether this conflicts with Rust's goals as a language (maybe it makes code harder to review), but bracket elision is definitely useful for prototyping volatile ideas. I know that I often wanna be able to prototype lots of changes (minor or major) without investing too much effort into each one, while also keeping the code easy to navigate.

2 Likes