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

Non-borrowing rust bindings #68

Closed
kvark opened this issue Feb 21, 2019 · 4 comments
Closed

Non-borrowing rust bindings #68

kvark opened this issue Feb 21, 2019 · 4 comments
Labels
type: enhancement New feature or request type: question Further information is requested

Comments

@kvark
Copy link
Member

kvark commented Feb 21, 2019

Related to #37 , also commentary from @omni-viral

Our current Rust bindings assume unique ownership over the IDs. This is idiomatic but sometimes inconvenient for the clients that need more freedom. Since our native layer is safe, we can have the IDs copyable on the Rust level as well, it's just going to be slightly different kind of API.

It would be nice not to fragment the community with another Rust wrapper. Perhaps, we can just control it by a feature? I.e.

#[cfg_attr(feature = "copy", derive(Clone, Copy))]
struct Buffer {
  id: BufferId,
}

impl<'a> RenderPassEncoder<'a> {
  #[cfg(feature = "copy")]
  pub fn end_pass(self) { ...
  }
}
@kvark kvark added type: enhancement New feature or request type: question Further information is requested labels Feb 21, 2019
@zakarumych
Copy link

It would be surprising for user that assume unique ownership to find out copies of his resources because another crate in dependency graph enabled that feature.

@kvark
Copy link
Member Author

kvark commented Feb 21, 2019

@omni-viral good point (although, again, it's not critical - it's not making the library unsafe). We should make it so that situation is impossible. The point of providing a feature here is not to allow different clients to enabled or disable it, but to keep the same code base.

@zakarumych
Copy link

I see what you mean. But this means user can't rely on uniqueness of the resource id if he gives a reference to it somewhere.
In this case I can't see any reason to have it under feature gate.

mitchmindtree pushed a commit to mitchmindtree/wgpu that referenced this issue Feb 23, 2020
68: remove usages of wgn in examples r=kvark a=rukai

This slipped through in gfx-rs/wgpu-rs#67

Co-authored-by: Rukai <rubickent@gmail.com>
kvark pushed a commit to kvark/wgpu that referenced this issue Jun 3, 2021
68: remove usages of wgn in examples r=kvark a=rukai

This slipped through in gfx-rs/wgpu-rs#67

Co-authored-by: Rukai <rubickent@gmail.com>
@cwfitzgerald
Copy link
Member

Superseded by #1453.

RandyMcMillan pushed a commit to RandyMcMillan/wgpu that referenced this issue Jun 19, 2024
Allow `Application` configuration with `Settings`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request type: question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants