These are chat archives for rust-lang/rust

30th
Jan 2017
Ivan Borgia Dardi
@ivandardi
Jan 30 2017 05:32
ok, so I'm making a discord bot and I want to add functionality to automatically compile code there using https://play.rust-lang.org/ I know it's possible, I just wasn't able to find how it expects me to sent the request to the page. does anyone know where I can find it?
Alexey
@KalitaAlexey
Jan 30 2017 19:29

How to wrap

#[macro_use]
extern crate somecrate;

into #[cfg(test)]?

Peter Atashian
@retep998
Jan 30 2017 19:31
#[cfg(test)] #[macro_use]
extern crate somecrate;
Alexey
@KalitaAlexey
Jan 30 2017 19:32
@retep998,
It's interesting. Is that anywhere described?
Peter Atashian
@retep998
Jan 30 2017 19:33
You can put #[cfg] on any item, including extern crate
If an item is cfg'd out, then any attributes attached to it are also gone
Alexey
@KalitaAlexey
Jan 30 2017 19:33
@retep998,
Oh. Thank you.
Kibeom Kim
@kkimdev
Jan 30 2017 19:55
Q: what's a recommended quick way to initialize VecDeque with few elements? Vec has vec![1, 2, 3] but it seems VecDeque doesn't have such a macro?
Tim
@tikue
Jan 30 2017 20:00
Hey. Is there a consensus on crates publicly reexporting types provided by other crates if they're part of the crate's public API? e.g. serde or libc?
the consensus in this thread seemed to be to publicly reexport types that are part of your crate's public API: https://www.reddit.com/r/rust/comments/3s43n4/discussion_lessons_learned_following_the_recent/?st=iykiuj7x&sh=6ea16dfd
but that doesn't work with serde Serialize/Deserialize, because you can't derive those traits more than once , for different versions of serde
so there's some inconsistency in approach there.
Peter Atashian
@retep998
Jan 30 2017 20:12
@tikue If a type from one of your dependencies is part of your public API, then whenever you bump the major version of that dependency you must also bump your own major version
Aleksey Kladov
@matklad
Jan 30 2017 20:19

@tikue the relevant Cargo issue is rust-lang/cargo#2064.

It is not implemented yet, so there's no ideal solution currently. You can expose your dependencies, but then the consumer of your library may end up with two versions of your dependency, which would not interoperate with each other. You can wrap all your dependencies, but this means more code in your crate, more code in the consumer's crate and potential runtime overhead because of marshalling effectively the same types back and forth.

Tim
@tikue
Jan 30 2017 20:22
@matklad thanks for the link to that issue!
Alexander Ronald Altman
@pthariensflame
Jan 30 2017 21:39
@kkimdev vec![…].into(). Type annotations may be required to disambiguate the result of the into call.