-
-
Notifications
You must be signed in to change notification settings - Fork 73
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
Remove use of nightly features #86
Conversation
MCHPRS/crates/core/src/blocks/mod.rs Lines 30 to 59 in 9774317
Isn't this better as trait BlockTransform {
fn rotate(&mut self, amt: crate::blocks::RotateAmt) {
// ...
}
fn rotate90(&mut self) {};
fn flip(&mut self, dir: crate::blocks::FlipDirection) {};
}
macro_rules! noop_block_transform {
($($ty:ty),*$(,)?) => {
$(
impl BlockTransform for $ty;
)*
};
} ? it would also allow easily implementing blocks that do rotate, but who's |
This is just a design choice that the person who wrote this did not choose to have default no-op bodies. AFAIK you can't do |
well, is it a good design choice? considering that's basically what the macro (previously blanket impl) is doing? |
Also the fact that the code compiles after this change shows that manual impls all have both |
Can you quickly update the building part of README? |
Done. I haven't touched the CI configs and Docker stuff. |
@StackDoubleFlow is this something that is desired? Requiring nightly would make it harder to package/build on linux distributions. Also if a user uses distribution provided rust then they can only use stable. |
Friendly ping, we are trying to package MCHPRS in Nixpkgs and nightly features makes it harder to package it. |
regex
'spattern
feature:find_iter
already does what is needed.BlockTransform
) This is more correct because when new blocks are added that need to implementBlockTransform
, someone could forget to implement and it will just fallback to the blanket impl instead (previous behavior) After this change any new types do not getBlockTransform
automatically and an impl must be added manually.once_cell
feature with theonce_cell
crate. As shown inCargo.lock
, this is already one of the transitive dependencies, so adding this as a dependency will not introduce more bloat.