When does Rust prefer to be implicit?

23

No you don't.

This is perfectly valid in Rust:

enum Foo { A, B, C } 

fn func(foo: Foo) {
    use Foo::*;
    match foo {
        A => {}, 
        B => {}, 
        C => {}, 
    } 
}
1 Like
24

I like to "express my intent explicitly" and the compiler to catch errors when I do it wrongly.
Clippy is not really good at finding shadowings. It get confused sometimes. And I love shadowing, so I don't want clippy to show me every shadowing I'm doing. Most of them are my intent and I don't want a false warning for those. I want to get warned only for the shadowings I didn't want to do. Does that make sense?

25

But is there any explicit rule of how to tell intentional shadowing from unintentional?

26

Today syntax does not give the possibility to the coder to express the intent.
Shadowing is implicit in the "let" keyword. It just happens.

27

Is there any reason why you can’t do this without the use in Rust? I do like how Swift does it using Type Inference.

28

Swift's type inference appears to work like C++'s type deduction. It's very basic in that every single variable has its type fully known at all times. Such a property is not true of Rust.

import Foundation

var x = []
x.append("hi")

/main.swift:5:9: error: empty collection literal requires an explicit type
var x = []
        ^~

In particular, one could do this:

enum Letter { A, B, C }

const A: u32 = 0;

fn main() {
    // is the type of `x` here u32 or Letter?
    let f = |x| match x {
        A => true,
        _ => false,
    };
    
    f(Letter::B);
}

(the current compiler says x is u32, and I imagine it would for all of the forseeable future, even if such a feature were added, meaning this snippet would still never compile. Nonetheless, on the surface this looks ambiguous in a manner that's not normally possible in Rust)

2 Likes
29

I see. Makes sense. Thanks for the explanation!

30

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.