3 ms·
> This is like complaining that in C [...] It's really not. Only one of my examples has the equivalent of superfluous parens, and none are dereferencing anyth
by xscott 11mo ago
> This is like complaining that in C [...]
It's really not. Only one of my examples has the equivalent of superfluous parens, and none are dereferencing anything. And I'm not defending C or C++ anyways.
When I was trying to learn Rust (the second time), I wanted to know how to make my own types. As such, the macro `vec!` mentioned elsewhere isn't really relevant. I was using `Vec` to figure things out so I could make a `FingerTree`:
let v: Vec<u32> = Vec::new(); // Awfully Java-like in repeating myself
let v = Vec::new(); // Crap, I want to specify the type of Vec
let v = Vec<u32>::new(); // Crap, that doesn't compile.
And so on...
- duped 11mo ago> let v = Vec::new(); // Crap, I want to specify the type of Vec This kinda implies you've gone wrong somewhere. That doesn't mean there aren't cases where you need type annotations (they certainly exist!) but that if `Vec::new()` doesn't compile because the compiler couldn't deduce the type, it implies something is off with your code. It's impossible to tell you exactly what the problem was, just that `<Vec<T>>::new()` is not code that you would ever see in a Rust codebase.
- gpm 11mo agoNah, there's lots of times you need to specify the types of Vec, either because 1. You don't want the default `i32` integer type and this is just a temporary vector of integers. 2. Rust's type inference is not perfect and sometimes the compiler will object even though there's only one type that could possibly work. Edit: The <Vec<T>>::new() syntax is definitely never used though.
- ViewTrick1002 11mo agoOr just collect::<Vec<_>>() when you have up doing everything in a lazy pattern and want a concrete type again. Which I guess i typical stumbling block when the compiler can’t infer what type to collect into.
- deleted 11mo ago[deleted]