These are chat archives for rust-lang/rust

19th
May 2016
Te-jé Rodgers
@mr-rodgers
May 19 2016 00:14
noob here. Is it possible to implement this trait for a reference type? http://ironframework.io/doc/iron/typemap/trait.Key.html
Chris Dawes
@cmsd2
May 19 2016 06:45
You can create an empty struct and use that as the key. The associated value type is probably what you want to experiment with. If it can be a reference it might need to be static. You might have more luck with an Arc wrapped value.
nishidy
@nishidy
May 19 2016 13:44
Hi, I tried to have self-recursive struct like associative link
struct Rst {
    f1 : i64,
    fst : Option<Rst>,
}
However, rustc says
wrap the inner value in a box to make it representable
it works with Box<Rst> in Option
How can I explain this? Box should be used if we have it on heap, right
Sergey Noskov
@Albibek
May 19 2016 13:45
Will it work if I used Option<&Rst> instead?
nishidy
@nishidy
May 19 2016 13:46
No. In that case, we need to specify lifetime on it
then, it is impossible to have different lifetime on recursive struct respectively
Zakarum
@omni-viral
May 19 2016 13:51
@nishidy What size this recursive object would have?
sizeof(Rst) = sizeof(i64) + sizeof(Rst)
... infinity
That's why this is impossible
Box<T> however have size of a pointer. No matter what
That's why you can have member of type Box<Self> in struct
Sergey Noskov
@Albibek
May 19 2016 13:53

@nishidy

#[derive(Debug)]
struct Rst<'a> {
    f1 : i64,
    fst : Option<&'a Rst<'a>>,
}

fn main() {
let rst1 = Rst{f1: 0, fst: None};
let rst2 = Rst{f1: 0, fst: Some(&rst1)};

println!("{:?} {:?}", rst1, rst2)
}

It only requires all lifetimes to be the same. So it's only about context.

Zakarum
@omni-viral
May 19 2016 13:53
@Albibek That one is OK. But this make object immovable
nishidy
@nishidy
May 19 2016 13:54
I put Option on inner field of struct. Then, it can be None. size should not be infinity, right?
Zakarum
@omni-viral
May 19 2016 13:54
@nishidy Nope
sizeof(Option<T>) == sizeof(T) + sizeof(marker)
Because Option<T> should be large enough to store T and enum marker
nishidy
@nishidy
May 19 2016 14:01
@Albibek That was the one that I had. I gave up using it because I could not have different lifetime on each struct in one list
@SCareAngel Box makes a pointer to the struct value, not struct value itself on variable, right
The reason why we need Option on it is because Box cannot have invalid pointer?
like null in c
Zakarum
@omni-viral
May 19 2016 14:11
@nishidy yes. Boxes always contain valid pointer
That's why there is a magic-optimization and Option<Box<T>> have same size as Box<T>
So you can put Option on Boxes without any memory overhead
nishidy
@nishidy
May 19 2016 14:41
good to hear. thanks
nishidy
@nishidy
May 19 2016 14:48
hi, it is not clear about the usage of *
fn f(s: &String){
    println!("{}",s);
    println!("{}",*s);
}
these are same result
some implicit operation works here?
Erik Hedvall
@Ogeon
May 19 2016 14:52
{} uses Display::fmt to display s, so it's the same as writing s.fmt(&mut formatter).
...and the same as s.to_string()
Zakarum
@omni-viral
May 19 2016 15:08
@nishidy The difference of your lines is same as
s.fmt(&mut formatter) and
(*s).fmt(&mut formatter)
Rust do auto-ref and auto-deref for method calling
So you can write println!("{}", &s) as well
nishidy
@nishidy
May 19 2016 15:14
Without auto-deref, *s is correct, right?
Zakarum
@omni-viral
May 19 2016 15:17
Since signature is Display::fmt(&self, &mut Formatter) I'm not actually sure )
Because (*s): String and auto-ref would be required
So I think s.fmt(...) is correct one. As Display::fmt(s, ... is
Note, that Display::fmt(*s, ...) is incorrect. Auto-ref/deref works only for self when method-call syntax is used
nishidy
@nishidy
May 19 2016 15:21
Ok, goot to hear. thanks
Daniel Collin
@emoon
May 19 2016 18:52
Anyone knows if it’s possible to change this code https://is.gd/uERXJN (play.rust-lang link) to get rid of the bounds checks inside the pack_data loop?
Erik Hedvall
@Ogeon
May 19 2016 19:32
I'm not so sure about that. I mean, chunks doesn't even guarantee that s has two elements.
Daniel Collin
@emoon
May 19 2016 19:46
ah yes that is true
I know that is the case but the compiler can’t know that
Erik Hedvall
@Ogeon
May 19 2016 19:47
Yeah...
Daniel Collin
@emoon
May 19 2016 20:34
Unrelated question. Is if possible to format!(…) to an exsting String instead of format returning a new String (thus causing allocations)
Zakarum
@omni-viral
May 19 2016 21:07
@emoon exising String is empty but with non-zero capacity?
Daniel Collin
@emoon
May 19 2016 21:07
yes
Zakarum
@omni-viral
May 19 2016 21:07
try to look to format_args!(...)
It gives you fmt::Arguments which is used by Formatter
Maybe Formatter can put data into existing string
Daniel Collin
@emoon
May 19 2016 21:13
will check. thanks!
Sean Perry
@shaleh
May 19 2016 22:04
@emoon https://is.gd/2TvTIf this may be enlightening
Zakarum
@omni-viral
May 19 2016 22:25
Or std::fmt::write with format!