The addition of NoTable is great; it's helpful for reclaiming a kilobyte or two on very constrained embedded systems. But, it only works if the user is vigilant about always doing Crc::<_, NoTable>::new() to specify the implementation they want. (Even if they use a OnceCell as suggested, nothing prevents someone elsewhere in the app or in a library from directly doing Crc::new() to get a default implementation.)
It would be nice if there were feature flags to enable implementations, so that a user could make NoTable the only available implementation, thereby preventing the larger Table<1> from creeping back into their binary by mistake.
Conversely, other users might want to make Table<16> the only available implementation, so that it's impossible to accidentally create a Crc using a slower Table<1> implementation.
The addition of
NoTableis great; it's helpful for reclaiming a kilobyte or two on very constrained embedded systems. But, it only works if the user is vigilant about always doingCrc::<_, NoTable>::new()to specify the implementation they want. (Even if they use aOnceCellas suggested, nothing prevents someone elsewhere in the app or in a library from directly doingCrc::new()to get a default implementation.)It would be nice if there were feature flags to enable implementations, so that a user could make
NoTablethe only available implementation, thereby preventing the largerTable<1>from creeping back into their binary by mistake.Conversely, other users might want to make
Table<16>the only available implementation, so that it's impossible to accidentally create aCrcusing a slowerTable<1>implementation.