These are chat archives for rust-lang/rust

24th
Dec 2018
aohan237
@aohan237
Dec 24 2018 02:34
which version of rust has support async/await syntax? and where can i find this document?
Björn Lindström
@bkhl
Dec 24 2018 02:48
aohan237, none yet, you may want to follow rust-lang/rust#50547
aohan237
@aohan237
Dec 24 2018 02:53
thanks
Zakarum
@omni-viral
Dec 24 2018 08:42
What do you guys think, what's worse: slight performance decrease, memory leak if API is used incorrectly?
Zakarum
@omni-viral
Dec 24 2018 08:59
By incorrectly I mean violating usage rules of unsafe methods.
Proton
@feisuzhu
Dec 24 2018 09:00
unsafe methods…… then they are on their own
Björn Lindström
@bkhl
Dec 24 2018 09:00
I wouldn't make design decisions based on that.
Zakarum
@omni-viral
Dec 24 2018 09:12

I have this situation. FFI wrapper (Foo) cannot guarantee safety entirely so it has few unsafe methods. Notably, dropping the wrapper is prohibited because it leads to resource leak. Now this wrapper can return from one of its methods another wrapper (Bar) with pointer to the same resource. So if Foo is dropped (which is already bad) the pointer in Bar becomes invalid which can lead to hard to debug errors.

I can make Foo a bit slower but send FFI resource to the allocator to properly destroy it on drop. And resource would have to be wrapped in Arc so that while Bar is alive it would hold resource from destruction. This will add overhead of ref-counting on Bar creation and destruction

Another possibility is to put resource in ManuallyDrop<Box<FFIResource>>. If Foo gets dropped then Box will be leaked, and pointer in Bar will stay valid. But this will be two leaks, resource and memory. Yet user will see that there is a problem (via controlled panic or error message) and fix it. No UB.

The entire thing is very perf-critical. Otherwise I'd choose overhead and made it entirely safe
So I think in my case leak with no UB can be acceptiable
Zakarum
@omni-viral
Dec 24 2018 09:23
Hmm. ManuallyDrop<Box<FFIResource>> can't be used :(
But NonNull<UnsafeCell<FFIResource>> can
Proton
@feisuzhu
Dec 24 2018 10:56
Hi, how can I force rustc to throw an error when I'm using the old Trait syntax over the new dyn Trait syntax?
Edvin Malinovskis
@nCrazed
Dec 24 2018 11:43
feisuzhu: do you mean specifically &Trait and Box<Trait>?
if so, I'd expect clippy to start flagging those by now
Zakarum
@omni-viral
Dec 24 2018 11:45
@feisuzhu #![deny(bare-trait-objects)]
Proton
@feisuzhu
Dec 24 2018 11:46

@feisuzhu #![deny(bare-trait-objects)]

wow, thank you~

Zakarum
@omni-viral
Dec 24 2018 11:46
But I would suggest denying this group #![deny(rust-2018-idioms)]
Which includes bare-trait-objects
Proton
@feisuzhu
Dec 24 2018 11:46
even better!
Zakarum
@omni-viral
Dec 24 2018 11:47
My default lint setup
#![forbid(overflowing_literals)]
#![deny(missing_copy_implementations)]
#![deny(missing_debug_implementations)]
#![deny(missing_docs)]
#![deny(intra_doc_link_resolution_failure)]
#![deny(path_statements)]
#![deny(trivial_bounds)]
#![deny(type_alias_bounds)]
#![deny(unconditional_recursion)]
#![deny(unions_with_drop_fields)]
#![deny(while_true)]
#![deny(unused)]
#![deny(bad_style)]
#![deny(future_incompatible)]
#![deny(rust_2018_compatibility)]
#![deny(rust_2018_idioms)]
I wonder if I can remove rust_2018_compatibility now
David O'Connor
@David-OConnor
Dec 24 2018 15:48
Does anyone know how to split a futures::AndThen across functions? It wants 3 type parameters, but I just want to expose one part of an and_then chain to an API
Tim Robinson
@1tgr
Dec 24 2018 15:54
If you want to return the result of .and_then() from your function, your best bet is to return impl Future
The full type of AndThen includes the type of your closure, which you can't write when you include it in your function's return type
David O'Connor
@David-OConnor
Dec 24 2018 16:04

That sounds like the soln, although not yet sure how to implement. Let's say we have this:

        // ... let f = 
        .and_then(|json_value| {
            // Do things internally
        })
         // We want to split and return the future here
        .and_then(|json| {
           // Let the user do things an in API
        });

We would do something like this?

        // ... let f = 
        .and_then(|json_value| {
            // Do things internally
        });

        let result : futures::Future = f.into();
        result
Tim Robinson
@1tgr
Dec 24 2018 16:22
No, return .and_then(|json| { ... }) directly (no ; at the end)
David O'Connor
@David-OConnor
Dec 24 2018 16:25
Thank you very much; will hack away at thish approach
(Or maybe have the API-user pass the cb, and don't return anything??
Tim Robinson
@1tgr
Dec 24 2018 16:27
Depends if the API wants to do something else with the result of the user code
Returning pub fn fn1() -> impl Future<Item = Something> is a pretty standard approach
If the user wants the API to do something else then they can do api::fn1().and_then(|json| api::fn2(json))
David O'Connor
@David-OConnor
Dec 24 2018 16:29
That approach is what I was think; would be more flexible than passing the CB. Eg I'm making a web framework where the cb-pass approach would work, but what would really be nice is a general wrapper around wasm_bindgen's poorly-documented fetch API, where that wouldn't work
David O'Connor
@David-OConnor
Dec 24 2018 16:37
Thanks Tim - your approach worked! In fact, I hadn't previously encountered<A = B> syntax. Merry Christmas'