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

Remove Into<Time> generics #352

Closed
wants to merge 1 commit into from

Conversation

burrbull
Copy link
Member

@burrbull burrbull commented Feb 4, 2022

Reason:
fugit uses it's own convertion technic and works bad with Into. Same as embedded-time don't use Into for potentially fallible convertions

@rust-highfive
Copy link

r? @therealprof

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added S-waiting-on-review Review is incomplete T-hal labels Feb 4, 2022
Copy link
Member

@eldruin eldruin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, with this change, we force people to use some type T instead of requiring only that Into<T> is available.
Could you elaborate why something like Into<T> is problematic?
If you already have T, as you would need to have if we merged this, then Into<T> should always be available, right?
What am I missing?

@burrbull
Copy link
Member Author

burrbull commented Feb 8, 2022

Could you elaborate why something like Into<T> is problematic?
If you already have T, as you would need to have if we merged this, then Into<T> should always be available, right?
What am I missing?

If you look at fugit::ExtU32 it let you pass 10.millis() type inference for automatic detecting of NOM and DENOM regardless of the resulting type. It works very well if resulting type is known (without any Into<T>). If you don't know resulting type than type inference don't work and you need to specify it by hand.

Saying about embedded-time Into<T> works only for part of conversions. Other require TryInto<T>

@eldruin
Copy link
Member

eldruin commented Feb 9, 2022

Thank you for bringing this up @burrbull.
As we agreed yesterday to merge #324 and thus remove the traits for now, I will close this.
However, we should definitely remember about this when we discuss the associated type constraints when adding the traits back.
Please bring this back up for proper discussion then if we forget about it.

@burrbull
Copy link
Member Author

If you look at fugit::ExtU32 it let you pass 10.millis() type inference for automatic detecting of NOM and DENOM regardless of the resulting type. It works very well if resulting type is known (without any Into<T>). If you don't know resulting type than type inference don't work and you need to specify it by hand.

Looks like this was fixed. But can't understand how.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Review is incomplete T-hal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants