This is a tracking issue for the RFC std::hint:_black_box.

Original RFC: RFC 2360

Public API:

// std::hint

pub fn black_box<T>(dummy: T) -> T;

Steps:

• Implementation
• FCP
• Stabilization PR

Unresolved questions:

• const fn: it is unclear whether bench_black_box should be a const fn. If it
  were, that would hint that it cannot have any side-effects, or that it cannot
  do anything that const fns cannot do.

• Naming: during the RFC discussion it was unclear whether black_box is the
  right name for this primitive but we settled on bench_black_box for the time
  being. We should resolve the naming before stabilization.

  Also, we might want to add other benchmarking hints in the future, like
  bench_input and bench_output, so we might want to put all of this
  into a bench sub-module within the core::hint module. That might
  be a good place to explain how the benchmarking hints should be used
  holistically.

  Some arguments in favor or against using "black box" are that:

  • pro: [black box] is a common term in computer programming, that conveys
    that nothing can be assumed about it except for its inputs and outputs.
    con: [black box] often hints that the function has no side-effects, but
    this is not something that can be assumed about this API.
  • con: _box has nothing to do with Box or box-syntax, which might be confusing

  Alternative names suggested: pessimize, unoptimize, unprocessed, unknown,
  do_not_optimize (Google Benchmark).