Lokathor/safe_arch

Remove super::* imports

Closed this issue · 5 comments

Soveu commented

It may be a good idea to replace super::* imports with imports to related types and core::arch::*

The current setup is arranged so that the use statements of things from outside the crate are in as few places as possible (just at the top of lib.rs), and then all sub-modules just use super::*; to grab those imports down to their own level.

I suppose it's just a personal style thing, but I think it's generally a fine way to have code arranged.

If it's causing confusion I suppose we could break it up.

I just don't like having to deal with imports when developing, so I try to arrange it so that changes to the imports happen as infrequently as possible. All the stuff the crate is using is just available at all times in all places within the crate, makes it very simple I think.

Soveu commented

I have an idea, where user imports for example safe_arch::avx and only has access to avx instructions.
It also means that documentation won't contain a big wall of instructions/macros right at the root.

I do genuinely like the big wall of functions, I think it's good. As a user of safe_arch, I basically want the docs to just like all the things that I can do and then let me pick.

But i'm also sympathetic to the idea that you might want to import only a sub-portion of the functions. Maybe the build overall will have access to more intrinsics than you want to import into the current module.

I'll try to think about a good way to do this.

So far the crate has mostly been oriented around being a "big dumb pile of stuff", and I've been trying to leave as many of the "cool and smart extra stuff" for higher-level crates that would depend on safe_arch.

Soveu commented

Take a look at #68, shows some of the crate in action.
I'd prefer to write sse::add_horizontal_m128, because I know where did it came from, but I also respect that it is your crate and you make the final decisions.

Well, we could just make the existence of the modules be public (in addition to the pub use statements), and then end users would be able to write it as sse::add_m128 if they wished to do it like that.