4 ms·
I don't see why exposing unsafe operations is problematic: the crate's user still has to explicitly decide to use them if desired. The normal compiler optimisa
by dbaupp 11y ago
I don't see why exposing unsafe operations is problematic: the crate's user still has to explicitly decide to use them if desired.
The normal compiler optimisations still apply to these functions, and they work reasonably well: https://news.ycombinator.com/item?id=9644119 https://news.ycombinator.com/item?id=9644119
Hm, what problem do you see with the closure? If it's just the `unsafe`... well, something has to touch the memory at some point.
- Animats 11y ago"I don't see why exposing unsafe operations is problematic: the crate's user still has to explicitly decide to use them if desired." Duh. The fact that someone felt it necessary to expose unsafe array access to the user indicates that the checking optimization has an overhead problem.
- dbaupp 11y agoI struggle to believe that subscript checking can be automatically removed in arbitrary code in any language (at least, not without full dependent typing), e.g. it seems pretty hard to make guarantees about something like x[y[i]] with arbitrary y.