These are chat archives for rust-lang/rust

6th
Apr 2019
Ghost
@ghost~5ca7017bd73408ce4fbcde34
Apr 06 01:26
did anyone know how to handel array out of bound error using. {ok() err()}
Ghost
@ghost~5ca7017bd73408ce4fbcde34
Apr 06 08:01
did anyone know
Michal 'vorner' Vaner
@vorner
Apr 06 08:20
Don't they have .get(i) that returns Option<T>? You get None if out of bound.
Ghost
@ghost~5ca7017bd73408ce4fbcde34
Apr 06 14:18
example code
David McGillicuddy
@djmcgill
Apr 06 19:03

I had a weird issue with trait objects and futures - my code was

    let request_future: Box<dyn Future<Item=Response<Body>, Error=Box<dyn std::error::Error>>> =
        Box::new(client.request(request).map_err(|e| Box::new(e)));

(please ignore the outer Box, that was only as a temporary type assertion)
which gave the error

   = note: expected type `std::boxed::Box<hyper::error::Error>`
              found type `std::boxed::Box<dyn std::error::Error>`

and I fixed it by adding an explicit cast: .map_err(|e| Box::new(e) as Box<dyn std::error::Error>)
How come this is required?

(I know this is the kind of thing that failure et al cover too)
Denis Lisov
@tanriol
Apr 06 19:08
Yes, sometimes this does not work without annotation... looks to me like rustc infers the closure return type to be Box<hyper::error::Error> from the closure and then notices it does not match the required Box<dyn std::error::Error>
David McGillicuddy
@djmcgill
Apr 06 19:11
Is as the correct solution? Or if it's a type inference issue seems like I can get by with a plain annotation
      .map_err(|e| {
          let b: Box<dyn std::error::Error> = Box::new(e);
          b
      })
Worked too, now I wonder if I can just provide map_err with some type params to do the same thing
Denis Lisov
@tanriol
Apr 06 19:14
For example, the following should work
    .map_err(|e| -> Box<dyn std::error::Error> { Box::new(e) })
David McGillicuddy
@djmcgill
Apr 06 19:16
.map_err::<_, Box<dyn std::error::Error>>(Box::new) // doesn't work
.map_err::<_, Box<dyn std::error::Error>>(|e| Box::new(e)) // does work
type inference is a fickle beast
Also I didn't realise you can specify closure return types like that, nice
yep, it works. I think that's probably the best variant
Sylwester Rąpała
@xoac
Apr 06 21:32
I have created a templates for azure pipelines for rust. ROAST ME :P
Alex Milkov
@amilkov3
Apr 06 21:42
hi. I was wondering if anyone has inside information (I guess if you can call it that haha) on whether Rust will support higher kinded types at some point in the future? I know its a touchy subject. Ppl oppose it as much as Go developers oppose generics because they dont want the Scala/Haskell category theory fest to flood in, which is a perfectly reasonable stance (opposing generics though i think is mostly silly haha). Anyway was just curious
toxicafunk
@toxicafunk
Apr 06 21:55
not the answer u're looking for but: https://gist.github.com/CMCDragonkai/a5638f50c87d49f815b8
Alex Milkov
@amilkov3
Apr 06 21:57

It is however on the roadmap.

where is he getting that assertion from?

Denis Lisov
@tanriol
Apr 06 22:04
Look at the RFC 1598, which is mentioned in the 2019 roadmap.
That's not the same as full-featured HKT, but a useful and understandable subset of them.
Alex Milkov
@amilkov3
Apr 06 22:05
right i was gonna say ive looked at associated types
David McGillicuddy
@djmcgill
Apr 06 23:11
FWIW I've not seen the same opposition in Rust as I have in Go
Geordon Worley
@vadixidav
Apr 06 23:13
I think they want to support things like HKT, but they want to do it in steps and make sure it's done right at every stage
Alex Milkov
@amilkov3
Apr 06 23:15
yea on second thought you're right. super subjective but: a lot more of the opposition I read about to generics in Go is based to a certain degree on group think rather than a delineation of pros and cons. Opposition to HKT from ppl in the Rust community is on more of a protective-of-the-community basis than any technical qualms other than: "do we really need this further abstraction?"
Geordon Worley
@vadixidav
Apr 06 23:16
well, I dont know if people think we shouldnt have it either, but more that there are several other priorities being worked on all the time
and if HKT can be implemented using a lot of smaller features like associated type constructors, then that might be a better design
there is just a large emphasis on doing the type system right in rust
Geordon Worley
@vadixidav
Apr 06 23:22
it has been merged
tracking issue rust-lang/rust#44265
as you can see though, there are other issues that are just more pressing atm and so this has not been a priority
if you are really interested, you can always go and try to implement it yourself =D
this issue is progress on "chalkification" rust-lang/rust#48049
Alex Milkov
@amilkov3
Apr 06 23:27
ah cool. yea wow there's a lot going on. haha i know jack about compiler theory and all that unfortunately
Geordon Worley
@vadixidav
Apr 06 23:28
chalk is just the solver engine they are plugging in for the trait system
it will allow you to have negative trait impls and enable a lot of these more advanced trait things
Alex Milkov
@amilkov3
Apr 06 23:28
although i mean i suppose to just come up with the API design you dont need to. Ive lived in Scala/Haskell for the past few years now so I'm use to their encodings of HKT
ill take a look
Geordon Worley
@vadixidav
Apr 06 23:29
well, they want to integrate everything with the trait system and such, plus everything in rust is typically statically dispatched and there is no garbage collector
so everything has to be zero cost when compiled
but yeah, there is tons of work going on now and always
const generics is a big thing that will land soon (TM) in nightly
it was a priority for years and it took a long time to prepare everything for it
I dont know the exact details though
but I have been following it very closely recently
mostly because everything I want to do is in some sense blocked by it =/
like right now I have a data structure for doing quick hamming space nearest neighbor lookups from a recent paper
except that I had to make it for just u128
because I cant properly abstract over all bit widths
once const generics merges then I wont have that issue though
Stephen Carman
@hntd187
Apr 06 23:35
I'm a bit confused, I use a Arc<RwLock<HashMap<...>>> in some code to protect a hashmap I share amoung threads
but reading stuff from ArcSwap and ParkingLot
makes me think maybe it should be RwLock<Arc<HashMap<...>>> instead
does it really matter?
Geordon Worley
@vadixidav
Apr 06 23:37
if you can already reference the RwLock immutably across threads then there is no need for the Arc, though I havent used ArcSwap and ParkingLot
all you need is just a way to give you immutable references to the RwLock
oh, you mean, put the Arc inside or outside
putting the Arc inside wouldnt help
unless you have access to the RwLock, but want to share the HashMap references
both of those do two different things
the first one lets you hold multiple references to the RwLock, the second one lets you hold a lock over a shared reference to the HashMap
which you might want, but you probably dont
I couldnt say without knowing what you want
alright, I am going to leave the gitter channel, but ill be on the Discord channel if anyone wants to have a follow up conversation with me
Stephen Carman
@hntd187
Apr 06 23:40
noo
wait
I'll explain lol
Geordon Worley
@vadixidav
Apr 06 23:41
hmm?
Stephen Carman
@hntd187
Apr 06 23:41
So basically the hashmap holds objects for a web service toaccess
and so the handler there takes a ref to the map gets what it needs
and it's done there
So it really doesn't need to pass around RWLocks
as much as the handler it self doesn't care how it gets the hashmap
just that it gets it
Geordon Worley
@vadixidav
Apr 06 23:42
so, the map is built at start and then isnt modified thereafter?
Stephen Carman
@hntd187
Apr 06 23:42
No it is modified
thus the RwLock
because some operations are modifying
Geordon Worley
@vadixidav
Apr 06 23:43
got it, and I assume your web service runs on many threads?
Stephen Carman
@hntd187
Apr 06 23:43
Yes, it's hyper
well it's tower-web, which uses hyper
Geordon Worley
@vadixidav
Apr 06 23:43
okay, and do you already have a way to get an immutable reference to a shared state?
I know actix-web and rocket would allow that
but I havent used tower-web
Stephen Carman
@hntd187
Apr 06 23:44
I mean if you're asking if my impl works
then yes, it does
it's currently Arc<RwLock<HashMap
Geordon Worley
@vadixidav
Apr 06 23:45
so I guess what I am getting at is
if the web service gives you the reference to the state for the handler
you dont need the Arc at all
Stephen Carman
@hntd187
Apr 06 23:45
The handler does not which is what I meant
Geordon Worley
@vadixidav
Apr 06 23:46
ahh, got it
Stephen Carman
@hntd187
Apr 06 23:46
So something like this
which is exactly what I'm talking about when this handler is constructed it takes it's own copy of the RwLock
Which I suppose means that it can give out it's own readers and writers to the underlying map
I'd imagine probably this approach has some issues with access contention but that probably doesn't break everything
Geordon Worley
@vadixidav
Apr 06 23:48
okay, so I dont know about this particular web service, but at least the way it is set up now where you have all state stored in completely independent structs and no shared struct on the server, then you must have the Arc<RwLock<>>
haofei
@Haofei
Apr 06 23:48
warn!("unknown completed load")));
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected usize, found ()
am I doing something wrong here?
Geordon Worley
@vadixidav
Apr 06 23:48
but if you can find a way for tower-web to give you a reference to shared state, then you can store the RwLock in there directly
but yeah, you do need the Arc there
its just a limitation of the current pattern
Stephen Carman
@hntd187
Apr 06 23:49
so i"m not doing anything loony or crazy wrong
Geordon Worley
@vadixidav
Apr 06 23:49
nope, it looks fine, but if you can get ahold of shared state, you could make it a little nicer I guess
I dont know if it would improve performance or anything though
what you are doing is fine
Stephen Carman
@hntd187
Apr 06 23:50
yea, it's make the ergonomics a bit nicer
Geordon Worley
@vadixidav
Apr 06 23:51
the only thing I would be careful of (not sure how much you know about web already) is just try to avoid storing actual state in the table that cant be lost and to use a database
its fine if its just for cachine purposes though
caching*
@Haofei lots of parenthesis on the right maybe?
could be part of a function call earlier in the code
I cant tell because you only sent that one piece
Stephen Carman
@hntd187
Apr 06 23:52
the hashmap itself is built at run time reliably so it'll always be good
and the values don't need to be persisted
because they are infered from disk
Geordon Worley
@vadixidav
Apr 06 23:52
ahh, got it, so its just like a cache of some sort
Stephen Carman
@hntd187
Apr 06 23:53
well the files on the disk are memory mapped files that are used
Geordon Worley
@vadixidav
Apr 06 23:53
oh, so its just storing the memory mapped files in the table
thats pretty interesting
Stephen Carman
@hntd187
Apr 06 23:54
it's an abstraction that tantivy (the library) does for the index
Geordon Worley
@vadixidav
Apr 06 23:54
is there a particular reason why you chose tower-web?
I dont know much about it currently
Stephen Carman
@hntd187
Apr 06 23:54
I chose tower web because I wanted to integrate with the whole tower stack, the services were in gotham originally
Geordon Worley
@vadixidav
Apr 06 23:55
ahh, I should look into tower and see whats going on with that then
thanks
Stephen Carman
@hntd187
Apr 06 23:55
yea, it's nice it handles a lot of my background grpc stuff for the clustering side
has impls for buffering requests, timeouts, reconnects retries
I guess I'll see how much well they work in high end practice but that remains to be seen
Geordon Worley
@vadixidav
Apr 06 23:56
yeah, as far as ergonomics go ive been a big fan of rocket, but I dont know if they have implemented async yet
Stephen Carman
@hntd187
Apr 06 23:57
stable only for me :(
I made a conscience decision to stop following what was in nightly so I didn't get green fields envy
Geordon Worley
@vadixidav
Apr 06 23:58
hah XD, fair
Stephen Carman
@hntd187
Apr 06 23:58
because thinking of nightly as "rust with more stuff" is a good way to shoot thy own foot
Geordon Worley
@vadixidav
Apr 06 23:59
I am actually using some nightly features at work, but only in libraries and binaries I am maintaining so if we need to take them to stable I can just go quickly clean up all the little feature requirements like box pattern syntax
Stephen Carman
@hntd187
Apr 06 23:59
Yea you don't have to box futures on nightly right?
Geordon Worley
@vadixidav
Apr 06 23:59
code with a lot of boxes and pattern matching can get pretty nasty without box syntax
yeah, you could use impl Future