-
Notifications
You must be signed in to change notification settings - Fork 432
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
Ergonomics of Interface::new
device parameter
#929
Comments
@TomCrypto I worked around this problem by creating a "dummy" device with the only purpose of providing the |
We indeed don't use the device when creating the interface, only the capabilities. We could indeed modify the function to take the capabilities instead of the device. However, I'm not sure about the implications. Maybe the reason why it was taking in a device was to have ownership of it. But I'm not sure if that is really necessary. Pinging @whitequark and @Dirbaio for this. |
Originally I'm not opposed to the change if others think it's a good idea, it just makes me a bit uncomfortable. |
I agree. I think originally I had it own the Device because then correctness is guaranteed by construction. But also, isn't it true that if you pass a One possibility is adding a |
Currently the
Interface
struct needs aDevice
to construct itself viaInterface::new
, but all it does with it is callcapabilities
on it. In some cases (e.g. embedded code) we would like to instantiate theInterface
before the device object can be constructed, even though we typically know the device capabilities upfront.Should
Interface::new
directly take aDeviceCapabilities
parameter instead of aDevice
?The text was updated successfully, but these errors were encountered: