I decided to use a bit of a heftier version of clippy to get myself ready for a version change. I was expecting some false positives but I'm not sure about this one. I got the following struct, and clippy tells me that every single function should be const. (clippy::missing_const_for_fn)
#[derive(Clone, Debug, PartialEq, Eq)]
pub struct ScheduleFields {
years: Years,
days_of_week: DaysOfWeek,
months: Months,
days_of_month: DaysOfMonth,
hours: Hours,
minutes: Minutes,
seconds: Seconds,
}
impl ScheduleFields {
// Constructor
pub fn new(
seconds: Seconds,
minutes: Minutes,
hours: Hours,
days_of_month: DaysOfMonth,
months: Months,
days_of_week: DaysOfWeek,
years: Years,
) -> ScheduleFields {
ScheduleFields {
years,
days_of_week,
months,
days_of_month,
hours,
minutes,
seconds,
}
}
// Getters
pub fn years(&self) -> &Years { &self.years }
pub fn months(&self) -> &Months { &self.months }
pub fn days_of_month(&self) -> &DaysOfMonth { &self.days_of_month }
pub fn days_of_week(&self) -> &DaysOfWeek { &self.days_of_week }
pub fn hours(&self) -> &Hours { &self.hours }
pub fn minutes(&self) -> &Minutes { &self.minutes }
pub fn seconds(&self) -> &Seconds { &self.seconds }
}
missing_const_for_fn
will suggest flagging asconst
anything which can be flagged thus. Regardless of it being useful or not.Here every single function can be const-ed, so clippy suggests doing that. And once you've marked them as const, clippy will find that most of their callers (which currently can't be const-ed because they call non-const functions) can also be const-ed.
Personally, I don't think this lint is useful or should be used: much like
Copy
,const
is a very strong and restrictive API promise. It should only be enabled on a case-per-case basis after careful consideration.