Closed clux closed 6 months ago
cc @Dav1dde who maybe has opinions
Not quite up to date, the main problem why hide-prelude
exists is to silence unused import warnings or allow easier import overrides?
I think instead of trying to be smart with imports another solution could be to just keep filling the prelude but hide all unused warnings etc.
#![allow(unused)]
mod prelude {
pub use std::collections::HashMap as Map;
}
use self::prelude::*;
// User supplied
use std::collections::BTreeMap as Map;
The generated code doesn't need to be perfect (it's machine generated after all), I've ran into similar issues in glad, where it's just better to take the solution which is readable enough but allows for way more flexibility in generation.
Not quite up to date, the main problem why
hide-prelude
exists is to silence unused import warnings or allow easier import overrides?
yeah!
I think instead of trying to be smart with imports another solution could be to just keep filling the prelude but hide all unused warnings etc.
#![allow(unused)] mod prelude { pub use std::collections::HashMap as Map; } use self::prelude::*; // User supplied use std::collections::BTreeMap as Map;
for some reason i didn't understand this the first time i looked at it, but now i think it makes sense. if people can shadow imports as parts of generation such as:
kopium X > crd.rs
echo "use mycrate::Map as Map;" >> crd.rs
then your setup there seems a lot easier to maintain, i'll try it out! sorry for the delay.
allows more control than
--hide-prelude
which disables everything, but is also likely to break for people who only override one struct, because we might add more structs to our prelude (as happened when we addedCondition
to our imports).following David's Idea below, the generated output now wraps imports in a private module:
so that to override any of these users can add extra overrides to any part of it using shadowing:
fixes #214