Pre-RFC: stabilization of target_feature

Yeah, thats a very good point in fact, that, I admit, makes most of the recent discussion moot. If we wanted static guarantees, we could just decide to not add the target_feature flag and instead force users to use the less powerful cfg(target_feature). Additionally, there seems to be already RFC 1868 which covers the topic lengthy, no need to re-invent the wheel here, although I guess as its a new feature we could be more strict with it. But let's not do it. I drop my demand to have such a way of checking :slight_smile: .

I was suggesting this change because I think that target_feature in its current form too unsafe for Rust which praises itself as "safe" language. All I want basically is that there should be no way to call a target_feature function from safe code and it SIGILLS, except some unsafe code that's outside of the language has made a mistake.

So my next proposal is very simple: just require every target_feature function to be an unsafe fn, and then external crates can come up with (proc) macros to call such a function and dispatch on it based on various criteria, from safe code.

1 Like