Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add stdlibx::prefix #13

Closed
vitiral opened this issue Jan 23, 2017 · 7 comments
Closed

add stdlibx::prefix #13

vitiral opened this issue Jan 23, 2017 · 7 comments

Comments

@vitiral
Copy link
Contributor

vitiral commented Jan 23, 2017

one of the things I really miss about langauges like python is that you don't have to clutter your import space in order to use most functionality.

That is not true with rust.

In rust, I frequently find myself writing dev_prefix files to import structs and traits that are necessary in practically every application.

Here is an example of a possible one for stdlibx:

//! `import stdlibx::prefix::*` so you can be ready to code!

// traits
pub use std::ascii::AsciiExt; // to_ascii_uppercase(), etc
pub use std::clone::Clone;
pub use std::convert::AsRef;
pub use std::default::Default;
pub use std::fmt::{Debug, Write as FmtWrite};
pub use std::io::{Read, Seek, SeekFrom, Write};
pub use std::iter::{FromIterator, Iterator};
pub use std::str::FromStr;
pub use std::ops::{Deref, DerefMut};

// structs
pub use std::collections::{HashMap, HashSet, VecDeque};
pub use std::ffi::OsString;
pub use std::path::{Path, PathBuf};
pub use std::rc::Rc;
pub use std::sync::Arc;

This list was basically put together because of the number of times I write a line of code and then hit compile and see that it doesn't work because of a forgotten import. It is quite annoying to not have access (by default) to std functions like from_iterator or write_str because you forgot to import a trait! It is almost as frustrating to be using a HashMap and realize it isn't defined. This is especially frustrating for newbies, so I see this lib as a possible (and effective) workaround.

@brson
Copy link
Owner

brson commented Jan 24, 2017

Hey that's a pretty neat idea! I've never really considered this matter of custom preludes before (I guess I'm pretty used to importing things).

I can easily imagine stdx having it's own prelude to export its own things. Reexporting upstream std features is quite opinionated though. If stdx were to do that it seems like the extended prelude for std would want to be in its own crate for maximum utility - perhaps not everyone wants to build all the stdx crates to get the extended std prelude.

On the other hand, if stdx adoption is a goal as a crate in its own right (I'm not sure it is yet), then having all those extra std imports available could be a differentiating feature.

@vitiral
Copy link
Contributor Author

vitiral commented Jan 24, 2017

This actually caused me to check whether a "prelude" crate exists... And it doesn't! Maybe I'll start one.

https://crates.io/crates/prelude

@vitiral
Copy link
Contributor Author

vitiral commented Jan 24, 2017

I went ahead and created the prelude crate to fill this niche. I think you are right that stdx isn't the right place for a stdlib prelude.

You can feel free to export my prelude in your prelude if you want to, as well as include new things like Regex, etc. My prelude is still pretty unstable though.

@theduke
Copy link
Contributor

theduke commented Jul 19, 2017

@brson Personally I'd love to have what vitiral has suggested.

It's also one of my biggest annoyances with Rust, and dumping a custom prelude in every crate and use ing it in every file is a pain.

Ideally I would just have to: use stdx::* to get both all the included crates (including std modules) and an extended std prelude into the namespace.

Comment regarding @vitiral s sample code above:

I would not re-export with a changed name, so pub use std::fmt::{Debug, Write as FmtWrite}; should drop FmtWrite.

Additiional items I would include:

pub use std::any::{Any, TypeId};
pub use std::cell::{Cell, RefCell};
pub use std::error::Error;
pub use std::time::{Duration};
pub use std::sync::{Mutext, RwLock};

// Maybe?
pub use std::fs::File;

pub use std::*;

pub use INCLUDED_CRATE_1;
...

Additionally, I would be in favor of very conservatively exporting common types from the included crates, but only for very popular crates and their most popular types.

Things I would think of immediately:

pub use chrono::{DateTime, Utc};
pub use uuid::Uuid;
pub use serde::{Serialize};
pub use serde::de::{Deserialize, DeserializeOwned};

@vitiral
Copy link
Contributor Author

vitiral commented Jul 19, 2017

@theduke the reason I renamed Write was because Write is imported from both io and fmt and is MOSTLY only used so that the traits can be used (i.e. in format!).

Probably if we rename one we should just rename both (i.e. pub use std::io:: IoWrite as well)

@theduke
Copy link
Contributor

theduke commented Jul 19, 2017

Yeah I realized why you did it that way, I'd just prefer not to rename any re-exports due to the confusion it could cause.

@vitiral
Copy link
Contributor Author

vitiral commented Aug 31, 2017

I'll close this for now. The prelude crate is in a pretty good state now if people want to use it!

@vitiral vitiral closed this as completed Aug 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants