These are chat archives for rust-lang/rust

5th
May 2019
Ghost
@ghost~5cc2f941d73408ce4fbebebe
May 05 07:23
@djmcgill is it possible to pass a multidimensional array with out specify it row and colum
eg

fn change_value(arr: &mut [i32]) {
arr[1] = 10;
}

fn main() {
let mut arr: [i32; 4] = [1, 2, 3, 4];
change_value(&mut arr);
println!("this is {}", arr[1]);
}

here it is a single dimensional array
we pass the array only by specify it's type i32
like that is t possible to pass a multidimensional array by specify it's type
Mac O'Brien
@cormac-obrien
May 05 07:38
@ebinshabu if you want to pass a multidimensional array without the dimensions, you have to pass it as a slice of slices, e.g. &[&[i32]]. If you try to pass a &[[i32]] the compiler will complain because [i32] is not Sized, so it doesn't know how large the elements of the outer slice are.
Denis Lisov
@tanriol
May 05 07:41
@ebinshabu Do you have any specific reason to avoid ndarray? Your questions sound like it would be a better option than arrays.
Ghost
@ghost~5cc2f941d73408ce4fbebebe
May 05 08:00
okk
Ghost
@ghost~5cc2f941d73408ce4fbebebe
May 05 09:07
is it possible to slice a two dimensional array without using ndarray
Ghost
@ghost~5cc2f941d73408ce4fbebebe
May 05 09:18
please help
Ghost
@ghost~5cc2f941d73408ce4fbebebe
May 05 12:11

is it possible to return an array from a function without define it’s size
eg:
fn create_array() -> [[usize; 50]; 50]

here we specify size of array as 50 before return it

meiedomi
@meiedomi
May 05 13:00

Hi there, noob here. Just working my way through the awesome "The Rust Programming Language" book. As I try to understand references and the borrowing rules, I came across the following simple code sample:

fn main() {
    let mut foo = 42;
    let a = &mut foo; // First mutable borrow here.
    let b = &mut (*a); // Rust doesn't seem to understand that '*a == foo' even though it knows that 'a' is a mut reference to 'foo'?
    *b = 55; // Here we are committing the crime: Change a value even though another mut reference is pointing to it...
    println!("Value is: {}", a); // Outputs 'Value is: 55'
}

Can anybody explain to me why it is so easily possible to effectively create two mutable references in the same scope, something the language should prevent as one of its core features?

Denis Lisov
@tanriol
May 05 14:08
@ebinshabu Once again: do you have any specific reason to ignore ndarray? Your questions sound like that's what you search for. Could you please explain why you don't consider it and/or why it does not work for you?
Denis Lisov
@tanriol
May 05 14:18

@meiedomi There is slight difference between &mut foo and &mut (*a).
The first tries to create a new independent mutable reference to foo and fails.
The second creates a new mutable reference to foo by borrowing it from a. For the duration b exists it is the only active reference to foo, while a cannot be used at all until we stop using b. Compare this with the following

let mut foo = (42, 42);
let a = &mut foo;
let b = &mut a.0;

it's almost the same - the second reference borrows from the first and deactivates it until no longer in use - but the reborrow is done for the whole structure, not for one field.

meiedomi
@meiedomi
May 05 14:34
@tanriol So is reborrowing a first-level concept? I don‘t find any documentation of it...
Ghost
@ghost~5cc2f941d73408ce4fbebebe
May 05 14:36
how to initialize mutidimensional vector and pass value to it
Ghost
@ghost~5cc2f941d73408ce4fbebebe
May 05 14:49
without using ndarray package
David O'Connor
@David-OConnor
May 05 16:17
Do y'all know if there's a datetime crate that works on wasm?
Chrono's popular, but does not: chronotope/chrono#287. Dead PR from half a year ago
Denis Lisov
@tanriol
May 05 17:44
@meiedomi Yes, reborrowing seems to be hardly documented :-(
@David-OConnor What specifically do you need from the crate?
Jim Hessin
@jhessin
May 05 18:02
Can someone tell me what I’m doing wrong here? I am working through the practice problems in the rust book and for some reason my “company” is coming up empty.
This message was deleted
Denis Lisov
@tanriol
May 05 18:30
@jhessin You mean in line 24, correct? Your mut is in a wrong place, it should be before data.
Jim Hessin
@jhessin
May 05 18:38
So line 15 should be data: mut HashMap::new(),
I’m not at my computer right now but I will try that later.
Jim Hessin
@jhessin
May 05 18:43
No it would be this line: data: mut HashMap<String, Vec<String>>,
The question is why doesn’t it give me an error if it’s a mutability issue.
Denis Lisov
@tanriol
May 05 18:55
It would be let Company { mut data } = self; instead of let mut Company{data} = self;
The latter is not valid syntax at all.
There are multiple other problems, however.
Jim Hessin
@jhessin
May 05 18:58
Okay I think we are looking at two different versions of the file.
Denis Lisov
@tanriol
May 05 18:59
Hmm... which branch did you want to link?
Jim Hessin
@jhessin
May 05 19:00
Yes I’m on the ‘work’ branch.
Denis Lisov
@tanriol
May 05 19:08
Did you really mean to call Company::new() inside the loop? :-)
Jim Hessin
@jhessin
May 05 19:12
Facepalm
Denis Lisov
@tanriol
May 05 19:12
Yeah, that happens :-)
Jim Hessin
@jhessin
May 05 19:12
That would be it. Thanks.
meiedomi
@meiedomi
May 05 21:04

I have another strange thing that I cannot wrap my head around:

fn main() {
    let mut x = 44;
    let y = &mut x;
    let z = &y;
    **z = 55; // Compiler message: "cannot assign to `**z` which is behind a `&` reference"
}

So x binds to the value 44, yis a mutable reference to x (i.e. I can mutate x via y), but y itself is not mutable. Then I have z, which is an immutable reference and itself immutable. According to my logic, *z should resolve one layer and therefore be equivalent to y, through which I actually can mutate x...

David O'Connor
@David-OConnor
May 05 21:14
@tanriol Full date/datetime/time functionality
Like Python or JS's built-in ones, or their popular third-party libs
or really, like Chronos
but working
Denis Lisov
@tanriol
May 05 21:30
@meiedomi If your path contains any immutable references, you cannot mutate over it, unless it's interior mutability.
meiedomi
@meiedomi
May 05 21:32
@tanriol So how exactly do I need to understand the semantics of & and &mut then? How to read it in English?
Denis Lisov
@tanriol
May 05 21:39
English is not my native language :-) normally I read them either as "immutable reference" / "mutable reference" or, more correct, as "shared reference" / "unique (exclusive) reference".
Normally modifying something requires you to have exclusive access, which means the path must not contain shared references.
meiedomi
@meiedomi
May 05 21:46
What I mean is this: If I take a & of something of type &mut i32, then I get something of type &&mut i32, I read this as „an immutable reference to a mutable reference to an integer“. Dereferencing this once gives me a „mutable reference to an integer“, and as the name suggests, allows me to mutate that damn integer! ;)
Denis Lisov
@tanriol
May 05 21:53

The problem is that you cannot "just" dereference that reference once. For example, what if you tried the following?

let zz = *z;

The compiler would tell you that you cannot move out the value z refers to because the reference z is immutable, and moving out is a mutation. You cannot copy it either because a &mut _ does not implement Copy (otherwise it would immediately become non-unique). **z thus is not "dereference, then dereference the resulting reference and assign to the place received", but a single operation.

meiedomi
@meiedomi
May 05 21:58
@tanriol cool, that first part makes sense! However, how would I call that single magical operation then?
Also, I am not really moving anything out if I don‘t use a let statement, or do I?
Denis Lisov
@tanriol
May 05 22:16
Not exactly sure about naming... one candidate is projection, from quick checking of the rustc source, but may be not exactly correct.
Or maybe I'm digging too deep :-)
Denis Lisov
@tanriol
May 05 22:21
Anyway, the compiler checks the whole path from named variable to the final field being modified and checks it as a whole.
meiedomi
@meiedomi
May 05 22:25
I appreciate your patience, however, the concepts of rust seem a bit convoluted, but I maybe just need to work more with it to arrive at a better intuition.