Named function arguments would occasionally be nice to have instead of the single n-tuple they take now. Currently I’m more or less playing a game of "can I name my local variables such that rust-analyzer won’t display the argument name when I stick them into functions (because they’re called the same)).
I was a bit apprehensive because rust has like a gazillion different function types but here it seems to work like just any other language with a HM type system.
Something i didnt know for a long time (even though its mentioned in the book pretty sure) is that enum discriminants work like functions
#[derive(Debug, PartialEq, Eq)] enum Foo { Bar(i32), } let x: Vec<_> = [1, 2, 3] .into_iter() .map(Foo::Bar) .collect(); assert_eq!( x, vec![Foo::Bar(1), Foo::Bar(2), Foo::Bar(3)] );Not too crazy but its something that blew my mind when i first saw it
This works with anything that one might call “named tuples”.
So, you can also define a struct like so and it’ll work:
struct Baz(i32);On the other hand, if you define an enum variant with the normal struct syntax, it does not work:
enum Foo { ... Qux { something: i32 } //cannot omit braces }Named function arguments would occasionally be nice to have instead of the single n-tuple they take now. Currently I’m more or less playing a game of "can I name my local variables such that rust-analyzer won’t display the argument name when I stick them into functions (because they’re called the same)).
Yea it’s like when we write
Some(2). It’s not a function call but a variant of theOptionenum.Enum constructors are functions, this typechecks:
fn foo<T>() { let f: fn(T) -> Option<T> = Some; }I was a bit apprehensive because rust has like a gazillion different function types but here it seems to work like just any other language with a HM type system.
Woah. That’s quite interesting. I didn’t know that.