4 ms·
I think some of the typing would be problematic, as it allows action at a distance. e.g. fn bar(i : &u16) { i + 1; } let a = 8; // a is a u8. b
by richardwhiuk 8y ago
I think some of the typing would be problematic, as it allows action at a distance.
e.g.
fn bar(i : &u16) {
i + 1;
}
let a = 8; // a is a u8.
bar(&a); // Now a needs to be a u16,
// but we executed the line of code
// above, which forced it to be u8.
// Is this a type error?
You can probably solve this, by requiring all blocks of code to be executed repl style to be standalone.
i.e. the above code is entered as:
fn bar(i : &u16) {
i + 1;
}
## Execution happens in the REPL
{
let a = 8;
bar(&a);
}
## Execution happens in the REPL.
And make the far above give "a not defined in this scope"
- steveklabnik 8y ago(small note, a would be an i32 here, not a u8. your point stands though)
- gpm 8y agoI think you solve this by just giving an error In [0] fn bar(i: &u16) { i + 1 } In [1] let a = 8; // a is a i32. In [2] bar(&a) Out[2] Type error: a is a i32 and it needs to be a u16 In [3] let a: u16 = 8; // The original a is shadowed by the new a, the new a is a u16 In [4] bar(&a) Out[4] 9 Or a similar situation where there isn't enough information to infer a type In [0] let x = Vec::new(); Out[0] Type error: Need to know the type of x In [1] let x: Vec<bool> = Vec::new(); In [2] x.push(true); // Note that if we had entered this at the same tiem as Vec::new() the type could have been inferred.
- richardwhiuk 8y agoThat forces you to write very unnatural Rust - it makes it a much clunkier language.