Pre-RFC: stabilization of target_feature

compiler
130

Random high-level comments from an outsider: (Sorry, I couldn’t resist. I hope this is useful feedback.)

  • I find it fairly confusing that target_feature sometimes tests whether the feature is available at compile-time, and sometimes changes the way a function is compiled. I.e., #[cfg(target_feature)] vs #[target_feature]. Is it really necessary for both to have the same name? I see there has been some discussion about this (unconditional_target_feature), but the RFC should mention why using the same name is still considered the best way forward. (As far as bikeshedding is concerned, I’d call them has_target_feature and use_target_feature, but whatever :wink: )
  • I also agree with the comments saying that there should be a way to test for features at run-time that uses the same syntax as the compile-time tests. The sample code further up that used Cpuid relies on being able to figure out which exact Cpuid flags correspond to which target features. Using the same “specification language” is just much better API design. #[target_feature] is fairly useless without run-time detection, so I think this is totally in scope for this RFC.
2 Likes