These are chat archives for rust-lang/rust

26th
Aug 2018
Frederic
@FredericChang
Aug 26 2018 04:21
I am a beginner,is it possible to use GUI like QT with Rust
Michal 'vorner' Vaner
@vorner
Aug 26 2018 07:04
Hello. I'm trying to return a closure that returns a future (actually, a struct containing this). And I'm trying to use impl Trait for that. But the compiler doesn't seem to let me (not allowed outside of function and inherent method return types). Is there a syntax, or is the answer for that „not yet, box them“? I tried impl for<'s> FnMut(&'s Arc<Spirit<S, O, C>>, TcpListener) -> impl Future<Item = (), Error = Error>
trsh
@trsh
Aug 26 2018 08:08
Need some advice.
What would be an fast and efficient way to compare to JSON serde VALUES, if they are identical in structure (not values)?
Michal 'vorner' Vaner
@vorner
Aug 26 2018 12:05
@trsh I'd probably replace all bools with true, all strings with empty ones, all numbers with zeroes… and then compare them for equality
Fantasized
@Fantasized
Aug 26 2018 13:46

Or when you assign it: let point: Point<i16> = Point { x: 5, y: 6 };

Thanks! I was trying stuff like Point<T> { x: 5, y: 6 };

Fantasized
@Fantasized
Aug 26 2018 14:08

@Fantasized, you can't declare a new struct with a specialized type. But you can impl FooTrait for Point<f32> {}

This is kinda boggling me, I've seen I could specialize methods, but I was thinking a scenario where,let's say I've an empty type struct noCoordinates{} (not sure what is the size of an empty type in rust, how to figure it out?) if suppose I am instantiating Point with type noCoordinates I should create x and y instance or at-least the the x & y would occupy few bytes space though they are of type noCoordinates, in that case, I thought I would specialize Point with no members/coordinates like struct Point<noCoordinates> { } which then let me to(I suppose ) create a Point with no coordinates let some : Point<noCoordinates> = Point {}, now the type specialization isn't allowed, what is the work-around then?

Fantasized
@Fantasized
Aug 26 2018 14:15

another question, if I instantiated type Point like Point { x:5, y:6}, what is the type of T here ? i8 or i16... how can I figure it out?

Use generic:

#[derive(Debug)]
struct Point<T> {
    x: T,
    y: T,
}

fn main() {
    println!("{:?}", Point { x: 0_i8, y: 0 });
    println!("{:?}", Point { x: 0_i16, y: 0 });
    println!("{:?}", Point { x: 0_isize,  y: 0 });
}

I ran this code, all it gives is kinda to_string() for a Point, I can't relate how it deals with a type argument T, am I missing anything?

Denis Lisov
@tanriol
Aug 26 2018 14:19

(not sure what is the size of an empty type in rust, how to figure it out?)

The size of a value of an empty type is zero, which you can verify with std::mem::size_of.

if I instantiated type Point like Point { x:5, y:6}, what is the type of T here?

If there's no additional information, integer types default to i32. However, if there is some additional information, the type may be inferred to any of the integer types.

Fantasized
@Fantasized
Aug 26 2018 14:27

(not sure what is the size of an empty type in rust, how to figure it out?)

The size of a value of an empty type is zero, which you can verify with std::mem::size_of.

thanks! So in rust, two instance of a zero byte type won't have the same memory address right?

Denis Lisov
@tanriol
Aug 26 2018 14:29
They can have the same memory address :-)
Fantasized
@Fantasized
Aug 26 2018 14:31
So you aren't bothered? if one instance dropped (due to scope/lifetime or whatever reason) and cleans up the memory the other one is dangling right?
Michal 'vorner' Vaner
@vorner
Aug 26 2018 14:32
What memory, if they take 0 bytes?
Fantasized
@Fantasized
Aug 26 2018 14:34
How it can take same "memory address" if it won't take any memory?
Denis Lisov
@tanriol
Aug 26 2018 14:34
There's no memory allocated for a zero-sized type, so there's nothing to clean up or free. A reference to it has some numerical value, but nothing is ever accessed using that address :-)
Fantasized
@Fantasized
Aug 26 2018 15:04
struct test{    // hope test is zero bytes
    x : empty,
    y : empty
}

impl test {
 pub fn testMethod(&self) - > empty{
               self.x // also hope accessing  x  wouldn't  cause any problem though "self " holds 
                           // a reference to some numerical value.
 }
}
trsh
@trsh
Aug 26 2018 16:52
@vorner I mean like a Value, that is abig JSON tree inside
Michal 'vorner' Vaner
@vorner
Aug 26 2018 17:04
@trsh I know. I meant something like canonicize(Value) -> Value that would basically map the thing recursively.
trsh
@trsh
Aug 26 2018 17:13
@vorner but order of props can be different
trsh
@trsh
Aug 26 2018 18:02
Anyway it's some recusive sh*
Matthew de Detrich
@mdedetrich
Aug 26 2018 18:41
Quick question, I heard somewhere that async/await is being planned for Rust in the future for abstracting over async IO, does anyone know if it would be similar to https://github.com/alexcrichton/futures-await ?
Also is there an RFC about this?
Ah actually found the RFC rust-lang/rust#50547, seems like the final syntax is still something to be decided
Robert
@rw
Aug 26 2018 19:01
i thought i understood trait bounds but i do not... could someone take a quick look at this short code snippet and help me understand what i'm doing wrong? https://play.rust-lang.org/?gist=e9937d1c6538a626edbed9b39d89d219&version=stable&mode=debug&edition=2015
Sylwester Rąpała
@xoac
Aug 26 2018 19:11
@rw Are u sure u using T as u want? impl<T: A> Z for T you probably want second T to be struct or enum not a parameter.
Robert
@rw
Aug 26 2018 19:13
@xoac like this? impl Z for A
Sylwester Rąpała
@xoac
Aug 26 2018 19:14
I am not an expert. Try first rustc --explain E0119 in your console
Robert
@rw
Aug 26 2018 19:17
@xoac i think the difference between that explanation and this situation is that i'm parameterizing over traits (HKT i think). however, impl Z for A works so i'll try to go with that. thanks! edit: nope, that means i need Self: Sized which is not permitted
Sylwester Rąpała
@xoac
Aug 26 2018 19:19
Aaa ok u want A i B impl Z? You can ensure it like this:
trait A: Z {}
trait B: Z {}
@rw
Robert
@rw
Aug 26 2018 19:21
@xoac i think it's the other way around :-) i'm implementing Z for A
Sylwester Rąpała
@xoac
Aug 26 2018 19:25
Yep. U are right. Sorry for misleading you.
Robert
@rw
Aug 26 2018 19:31
i think i understand what's going on: there could be a type that implements both A and B, and then these impls would conflict
Avi Srivastava
@k3yavi
Aug 26 2018 20:11
hey guys, any idea what am I doing wrong here
Even though StdRng seems to have implemented the new here, but the above playground link keeps giving me error, no function or associated item namednewfound for typerand::StdRngin the current scope
Denis Lisov
@tanriol
Aug 26 2018 20:17
Looks like you're using outdated documentation. Look at using StdRng::from_entropy
Avi Srivastava
@k3yavi
Aug 26 2018 20:20
Thanks a lot @tanriol , one more very stupid question, how do one know that the doc is old ?
Denis Lisov
@tanriol
Aug 26 2018 20:23
I usually use docs from docs.rs and check the latest version there. Alternatively, if you're building locally, cargo doc will build documentation for the exact version you're using.
(not exactly sure which one will be built if you have more than one version in the dependency graph, however)
Avi Srivastava
@k3yavi
Aug 26 2018 20:24
Awesome! Thanks again for the tip !!
Sylwester Rąpała
@xoac
Aug 26 2018 20:30
@k3yavi add --open to cargo doc and it will open in browser after build.
Avi Srivastava
@k3yavi
Aug 26 2018 20:31
:thumbsup:
Sylwester Rąpała
@xoac
Aug 26 2018 20:52
I use a lot of u32 as usize and usize as u32. How I can tell rust to block compile on platform with usize smaller than u32?
Christopher Sabater Cordero
@cs-cordero
Aug 26 2018 23:19
Hey everyone -- Rust noob here. Trying to wrap my head around a borrow issue related to HashMap
I'm trying to do one of the suggested problems in the Rust book
Avi Srivastava
@k3yavi
Aug 26 2018 23:20
Can you please give a playground link w/ the issue ?
Christopher Sabater Cordero
@cs-cordero
Aug 26 2018 23:21
impl<T> Cacher<T>
    where T: Fn(u32) -> u32
{
    ...
    fn value(&mut self, arg: u32) -> u32 {
        let value = self.values.get(&arg);
        match value {
            Some(&v) => v,
            None => {
                let v = (self.calculation)(arg);
                self.values.insert(arg, v);
                return v;
            },
        }
    }
}
so basically i've got a Cacher struct that has a values HashMap
the idea is that when value gets called, it should check the hashmap if the arg has been used before, and if so, then return the cached value, otherwise call a closure function held in self.calculation, and cache the result before returning the value
my error is much simpler than that though... basically the first self.values.get(&arg); is seen as immutable
and then the .insert line is viewed as mutable, and so the compiler is complaining
oh a playground link... hmm let me make one
Christopher Sabater Cordero
@cs-cordero
Aug 26 2018 23:26
there you go, sorry i didn't notice your message before spamming the chatroom
Denis Lisov
@tanriol
Aug 26 2018 23:28
This is one of the things that should just work after NLL comes, but for now there's the entry API
Christopher Sabater Cordero
@cs-cordero
Aug 26 2018 23:28
forgive my ignorance -- what is NLL, and what is the difference between get and entry?
Denis Lisov
@tanriol
Aug 26 2018 23:29
NLL is non-lexical lifetimes (you may hear this sometimes), which is coming with 2018 edition, IIUC.
Christopher Sabater Cordero
@cs-cordero
Aug 26 2018 23:31
uh hmm, how is the lifetime relevant here?
does it have something to do with self.values being immutably borrowed? does that change the lifetime or something...?
Denis Lisov
@tanriol
Aug 26 2018 23:32
With the entry API, your function can look like
    fn value(&mut self, arg: u32) -> u32 {
        let calculation = &self.calculation;
        *self.values.entry(arg).or_insert_with(|| calculation(arg))
    }
Yes, self.values is currently considered borrowed until the get's return value dies (or longer if the reference is passed furtherer).
Christopher Sabater Cordero
@cs-cordero
Aug 26 2018 23:34
OH!! that kind of makes sense
i put down reading the book for a while and forgot about how lifetimes worked
Denis Lisov
@tanriol
Aug 26 2018 23:34
For your return value type we could actually pull a trick using the fact they're Copy, but I'm not sure whether you want to have this as a design requirement :-)
Christopher Sabater Cordero
@cs-cordero
Aug 26 2018 23:37
yeah? whats the trick?