Wgpu-rs: Modularize the API

[Yamakaky]

Currently, the wgpu crate is a big bag of structs and enums (https://docs.rs/wgpu/0.6.0/wgpu/). Did you consider migrating to an API using modules? For example, you would have the texture buffer with all the Texture* elements. Optionally, the elements could be renamed to remove the prefix, for example texture::View instead of texture::TextureView.

One big advantage is to improve the discoverability of the API. Everything is grouped in logical groups and each module doc can include some explanation of key concepts.

Downside: a lot of things to rename in the reverse dependencies. Should be straightforward to fix though.

I can do a draft if you are OK with the idea.

[kvark]

I believe Rust ecosystem hasn't converged into either module-full or module-less approach on the crate API side. There are proponents of both, and we are considering this for a case-by-case basis. For wgpu, there aren't too many types and structs (e.g. comparing to gfx-rs). Besides, putting everything in one namespace lets us use the exact terms of WebGPU specification. Otherwise, we'd either have an awkward wgpu::texture::TextureFormat or a diverging wgpu::texture::Format, for example. So all in all, I think we should keep working in the same namespace here.

[Yamakaky]

You can keep the same public API by adding multiple pub use mod::* in either the root or a prelude. As mentionned, I think having modules exposed would add a lot to the discoverability of the API.

[kvark]

Wait, I'm confused. Are you suggesting to add modules in the public API (this is how I read your OP), or just internally?

[Yamakaky]

Something like https://docs.rs/smol, with modules including texture, buffer... In addition and to stay similar to the webgpu spec, you can import everything in either the crate root or a prelude module. That way you keep both options.

[grovesNL]

I'd prefer to keep it flattened and keep the names consistent with the WebGPU API like @kvark mentioned. This is important because it means it's much easier to lookup the Rust name directly in the WebGPU specification, or translate examples in other languages (e.g. JavaScript/TypeScript) to Rust without having to look for the correct Rust module to import it from.

Having both options might make things slightly more confusing because examples, tutorials, etc. will have their own preference of whether to use the fully-qualified path to types. It would also mean that users would have to choose between multiple types when trying to import types through their IDE (e.g. with rust-analyzer).

[cwfitzgerald]

Closing for now as there seems to be a consensus to keep the API as it is, but feel free to keep discussing, and re-open if necessary!