These are chat archives for rust-lang/rust

30th
May 2018
Farzeen
@thefzsalam
May 30 2018 06:50
:+1:
Uli Schlachter
@psychon
May 30 2018 07:25
Hi, can someone shed some light on why std::collections::LinkedList has unsafe impl<T: Sync> Sync for LinkedList<T> {}? Just because I put AtomicUsize instances into a LinkedList does not mean that the list modification itself suddenly becomes thread safe, or am I missing something? (Similar question for Send, although that might actually be fine(?))
Uli Schlachter
@psychon
May 30 2018 07:49
And once again I am confused by Send and Sync: Assuming the above is actually fine and I was wrong, why isn't e.g. usize also Send and Sync?
Uli Schlachter
@psychon
May 30 2018 08:21
Hm, okay, usize is Sync, but this is just not shown in the docs... never mind then and sorry for the noise
Zakarum
@omni-viral
May 30 2018 08:43
@psychon std::collections::LinkedList is not Sync automatically because it contains !Sync fields.
But it's ok to read from LinkedList from multiple threads. So it needs to be manually marked as Sync.
Sync doesn't allow you to modify anything from multiple threads cause you can't share &mut anyway. It only allows you to Send & across threads
That's why wrappers that adds interior mutability usually not Send nor Sync (such as RefCell) except those provide synchronization by themself (Mutex)
Uli Schlachter
@psychon
May 30 2018 08:46
Yup, thanks, I learned something about the interplay between "only one mut borrow" and Sync
And I actually missed the first reason (!Sync fields in the struct)
Zakarum
@omni-viral
May 30 2018 12:23
Rule 423: Don't put code with side effects into asserts
Dmitriy
@dpogretskiy
May 30 2018 12:39
@omni-viral what a boring suggestion :laughing:
do asserts exist in --release builds?
Zakarum
@omni-viral
May 30 2018 12:40
No if it is debug_assert*
I was wonder why xfg examples crashes in release.
Just found the bug. One small but crutial side effect was put into debug_assert! :/
Sylwester Rąpała
@xoac
May 30 2018 14:02

How should be Builder crated?

fn add_sth(&mut self) -> &mut Builder {self}

or

fn add_sth(mut self) -> Builder {}
Dmitriy
@dpogretskiy
May 30 2018 14:02
second
Sylwester Rąpała
@xoac
May 30 2018 14:02
why?
Dmitriy
@dpogretskiy
May 30 2018 14:03
because it's not builder otherwise, and just throws bunch of references around
well, it's actually mutable builder vs immutable builder
Sylwester Rąpała
@xoac
May 30 2018 14:04
mutable builder. I want to use some set method
Dmitriy
@dpogretskiy
May 30 2018 14:04
with mutable builder can't chain .build() to the end, and hope builder will be consumed
so i think it doesn't matter all that much, but i'd prefer immutable builder any day
Sylwester Rąpała
@xoac
May 30 2018 14:06
How can I make immutable builder?
Dmitriy
@dpogretskiy
May 30 2018 14:06
mutable builder of this sort can be used as kind Factory
Dmitriy
@dpogretskiy
May 30 2018 14:06
just consume builder on every step
with mutable builder it's really easy to misuse it, i did that bunch of times :smile:
Dylan DPC
@Dylan-DPC
May 30 2018 14:07
how?
Sylwester Rąpała
@xoac
May 30 2018 14:07
Ok thx. It work for me either :)
Dmitriy
@dpogretskiy
May 30 2018 14:09
just spagetti-code nothing fancy
with immutable builder it's really easy too, but not in rust thankfully, since it actually is consumed and you can't use any of the 27 versions of it :smirk:
which is totally possible in GC languages, huh
Sylwester Rąpała
@xoac
May 30 2018 14:13
I like it. I was inspirited from reqwest but in one place I need to consume reference.. So love rust <3
Dmitriy
@dpogretskiy
May 30 2018 14:15
rust builders are funky
they might or might not be reusable for better or worse, lol
@xoac you can also look at Default trait for ultimate mind blowing experience, it can be more useful depending on your case.
here
Sylwester Rąpała
@xoac
May 30 2018 14:18
I know it :)
Dmitriy
@dpogretskiy
May 30 2018 14:18
looks pretty "builder, without actual builder" to me
and use it as Request { url, query, ..Default::default() }
Dylan DPC
@Dylan-DPC
May 30 2018 14:20
@dpogretskiy do you have an example of immutable builder going wonky?
Dmitriy
@dpogretskiy
May 30 2018 14:27
@Dylan-DPC it's not exactly going wonky for builder itself, but ordinary brainfart on my part, like in if statements
Dylan DPC
@Dylan-DPC
May 30 2018 14:27
ah ok
Dmitriy
@dpogretskiy
May 30 2018 14:28
better safe then sorry, rust is secured from that, thankfully
Restioson
@Restioson
May 30 2018 14:48
@dpogretskiy &mut self -> &mut Builder is preferred (both imo and in a rust style guide thingie i found on some core dev's website, maybe aturon, don't remember, was a while ago)
so you can do stuff like
let mut builder = Builder::new()
    .add(1)
    .subtract(2)
    .multiply(5);

builder.power({ /* long code */ result });

let num = builder.build();
instead youd have to carry on doing builder = builder.thing
Sylwester Rąpała
@xoac
May 30 2018 14:52
yes, but u can't move things from builder on the finish() or send()
   |
36 |     let file_info = c.file_add(data).set_journal("test_journal").send();
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot move out of borrowed content
Dmitriy
@dpogretskiy
May 30 2018 14:53
yeah, that's exactly my point
it's handy with if's and stuff, but you can't write a fancy one-liner
Sylwester Rąpała
@xoac
May 30 2018 14:54
here send took mut and set_journal & mut
Restioson
@Restioson
May 30 2018 14:54
Then you just do it as a statement
Dmitriy
@dpogretskiy
May 30 2018 14:55
yeah, you can't consume value by reference, without explicitly cloning if it's even possible
Restioson
@Restioson
May 30 2018 14:55
c.file_add(data).set_journal("test_journal");
let file_info = c.send();
Dmitriy
@dpogretskiy
May 30 2018 14:55
yeah, it doesn't really matter all that much in the end
personal preference at max
Sylwester Rąpała
@xoac
May 30 2018 14:56
I return builder and expect that user can just call send() on it.
Dmitriy
@dpogretskiy
May 30 2018 14:56
it's a huge difference in other languages tho
tandrysyawaludin
@tandrysyawaludin
May 30 2018 15:53
is there another choice beside JWT in rust?
Berkus Decker
@berkus
May 30 2018 15:56

is there another choice beside JWT in rust?

I use https://crates.io/crates/medallion

David Harvey-Macaulay
@alteous
May 30 2018 20:42
Are there any best practices for returning errors for crates? I'm currently returning a single enum for all possible scenarios. I was wondering if it was worth making an abstraction like std::io::{Error, ErrorKind} instead.
pub enum Error {
    Deserialize(Error),
    Glb(Error),
    Validation(Vec<(Path, Error)>),
}
Berkus Decker
@berkus
May 30 2018 20:53
use Failure
David Harvey-Macaulay
@alteous
May 30 2018 20:55
That's not really the answer I'm looking for. I don't want to impose dependency hell on my users.
Berkus Decker
@berkus
May 30 2018 20:56
ok, alternative is to reinvent failure yourself and then answer endless tickets "Why didn't you just use failure?"
Avi Srivastava
@k3yavi
May 30 2018 20:56
tbh you asked for the best practice, I think @berkus is right.
Stefan Kaufhold
@skaufhold
May 30 2018 20:57
Just an enum is fine too if your crate is small enough to make that not too messy, I think it integrates with Failure quite easily
But if you find that too limiting, Failure is the way to go in my opinion
Berkus Decker
@berkus
May 30 2018 20:59
I've seen library crate authors use failure and/or error-chain and haven't felt any dependency hell yet - it's the same cargo build either way.
Stefan Kaufhold
@skaufhold
May 30 2018 21:01
My approach is basically "use an enum if I'm making something super simple/small, for more complex stuff use failure"
David Harvey-Macaulay
@alteous
May 30 2018 21:02
Okay, that'll do, thanks.