These are chat archives for rust-lang/rust

6th
May 2019
Benjamin Cordes
@benjyz
May 06 04:46
Hi, I am looking for basic example to use rust & sqlite. most snippets I have found are outdated.. eg https://docs.rs/rusqlite/0.18.0/rusqlite/
Denis Lisov
@tanriol
May 06 08:22
By "outdated" do you mean "no longer works"?
Also you can try diesel (sqlite examples)
Zakarum
@omni-viral
May 06 13:54
@meiedomi otherwise you would be allowed to share mutable reference through shared reference and then mutate value from different places
i.e.
let mut x = 1;
let y = &mut x;
ley z0 = &y;
let z1 = z0;
// Now both `z0` and `z1` are references to mutable reference.
let boom0 = *z0;
let boom1 = *z1;
// Whoa. `boom0` and `boom1` are two mutable references to the same location.
// That's why this is not allowed.
In practice &&mut T is almost &&T except that former is not covariant over T.
meiedomi
@meiedomi
May 06 19:15
@omni-viral Isn‘t let z1 = z0 a move and thus renders z0 unusable?
What do you mean by „covariant“?
Zakarum
@omni-viral
May 06 19:15
@meiedomi No, because shared references are copiable
meiedomi
@meiedomi
May 06 19:16
I see, makes sense!
So I really have to regard multiple dereferences in a row as just only logical operation?
Zakarum
@omni-viral
May 06 19:17
No. It just you don't get owned value by dereferencing
*x does not give you ownership to whatever x references
Unless the value is a Copy, then you may say that you get ownership of the copy
Since you don't own mutable refenence, nor borrow it mutably, you can mutate through it.
That's why **x = 2 will give you error if x has type x: &&mut T.
Even if you write it like this *(*x) = 2
The second variant will result in different error message probably
Because expression (*x) tries to move (i.e. get ownership) the value referenced by x
meiedomi
@meiedomi
May 06 19:27
Yeah I immutably borrow a mutable reference with &&mut T, which I interpret as „I cannot mutate the borrowed reference, but I can mutate the value through the borrowed mutable reference“
Zakarum
@omni-viral
May 06 19:27
It should be called unique actually
&share &uniq T
After you share unique borrow, it is no longer unique )
meiedomi
@meiedomi
May 06 19:28
But that seems to be wrong, as the meaning of an immutable reference seems to be „you cannot mutate that what it points to, and neither anything reachable from there“
Zakarum
@omni-viral
May 06 19:29
That's semantics of shared reference in Rust
It goes through structures as well.
If you have shared reference to structure that contains mutable reference - you cannot mutate through it
meiedomi
@meiedomi
May 06 19:32
Yeah interpreting it like that makes more sense. However, what gets me confused is when I look at the types: dereferencing a &&mut T must give a &mut T, and the latter would allow me to change the value.
Zakarum
@omni-viral
May 06 19:33
Dereferencing does not gives you that
meiedomi
@meiedomi
May 06 19:33
So when I do *(*x), what is the intermediate type ?
What else would it give me?
Zakarum
@omni-viral
May 06 19:33
It can give you a copy, if referenced type is copiable
If it is not - then that expression is not valid
meiedomi
@meiedomi
May 06 19:34
Let‘s say it is not copyable
Like a struct
Zakarum
@omni-viral
May 06 19:35
*x is not a value
meiedomi
@meiedomi
May 06 19:35
It‘s a mutable reference to s value
Zakarum
@omni-viral
May 06 19:35
You can only do so much things with it.
Like go back to reference &*x
Or call a method (*x).foo()
Or copy it let y = *x; or foo(*x). If it's copiable
meiedomi
@meiedomi
May 06 19:37
What, then, is the type of *x?
Zakarum
@omni-viral
May 06 19:37
That's the point. It is not complete expression
meiedomi
@meiedomi
May 06 19:37
If x is &&mut T
Zakarum
@omni-viral
May 06 19:38
On it's own it tries to do a copy and then it is &mut T. yet copying is unavailable
Ichoran
@Ichoran
May 06 19:38
Keep in mind that when you dereference something it never has exactly the same type as the original. You can't reborrow it as mutable, for example.
Zakarum
@omni-viral
May 06 19:39
You may think as &* operator of "reborrow as shared" and &mut * as "reborrow as mutable".
The second one can only be applied to &mut T
And singular * operator as "copy referenced value"
Except it also can be used as lvalue. i.e. *x = y where it has different semantics
meiedomi
@meiedomi
May 06 19:47
So this reborrow stuff is a special case? So &* cannot be considered as a simple composition of & applied after *?
Or is it just a term we give to mean that specific pattern?
meiedomi
@meiedomi
May 06 19:56
Can it be that a reference type starting with & is never the type of a value, but rather a type of a binding? I.e. a type of an lvalue?
Artemov Ivan
@ZOXEXIVO
May 06 20:18
Hello. Who can explain, why i need mark my struct #[derive(Deserialize) for deserialization ?
Why i can't deserialize it like in other languages ?
matrixbot
@matrixbot
May 06 20:19
bspeice What other languages are you referring to?
Denis Lisov
@tanriol
May 06 20:19
@ZOXEXIVO There's no runtime type information for serialization. It's done with Serialize/Deserialize traits provided by the serde library.
Artemov Ivan
@ZOXEXIVO
May 06 20:22
@tanriol thanks
it's really annoing
Denis Lisov
@tanriol
May 06 20:26
On the other hand, with derive and serde attributes you can customize the serialization as you need :-)
Zakarum
@omni-viral
May 06 20:47
This message was deleted
@meiedomi &{*x} and &*x are different things
First one creates a copy of the value and then gets reference to it
Second one reborrows original value
But &(*x) is the same as &*x
Which again shows us the fact that type of *x is not T where x: &T
Ichoran
@Ichoran
May 06 20:51
@ZOXEXIVO - It's reasonable to allow things that can't be serialized and/or deserialized, so it makes sense to have to ask for it. I grant that the derive mechanism is pretty verbose, though. (It's way way less verbose and error-prone than trying to do it yourself, but yeah, maybe there's still room for improvement.)