Tracking issue for libcore prelude traits

[alexcrichton]

These are currently all unstable but part of the libcore prelude.

This is currently intentional, but the fact that they need to be unstable is somewhat unsettling. Arguably all unstable features in libcore should be on the path to deprecation or stabilization at some point.

[Mark-Simulacrum]

I believe that libcore is now mostly stable, aside from those below. As far as I can tell, none of these are directly in the prelude, though I may be wrong. Perhaps this can be closed?

   1 src/libcore/fmt/mod.rs: fmt_flags_align
   1 src/libcore/hash/mod.rs: sip_hash_13
   1 src/libcore/iter/range.rs: trusted_len
   1 src/libcore/iter/traits.rs: exact_size_is_empty
   1 src/libcore/iter/traits.rs: iter_rfind
   1 src/libcore/macros.rs: concat_idents_macro
   1 src/libcore/marker.rs: unsize
   1 src/libcore/slice/mod.rs: slice_get_slice
   1 src/libcore/sync/atomic.rs: compiler_fences
   1 src/libcore/sync/atomic.rs: future_atomic_orderings
   2 src/libcore/fmt/mod.rs: never_type_impls
   2 src/libcore/hash/mod.rs: i128
   2 src/libcore/iter/sources.rs: trusted_len
   2 src/libcore/iter/traits.rs: fused
   2 src/libcore/iter/traits.rs: trusted_len
   2 src/libcore/ops.rs: question_mark_carrier
   2 src/libcore/option.rs: option_entry
   2 src/libcore/ptr.rs: offset_to
   2 src/libcore/slice/mod.rs: trusted_len
   2 src/libcore/str/mod.rs: str_internals
   3 src/libcore/char.rs: try_from
   3 src/libcore/cmp.rs: reverse_cmp_key
   3 src/libcore/iter/sources.rs: fused
   3 src/libcore/ops.rs: fn_traits
   3 src/libcore/option.rs: fused
   3 src/libcore/option.rs: trusted_len
   3 src/libcore/result.rs: fused
   3 src/libcore/result.rs: trusted_len
   3 src/libcore/slice/mod.rs: sort_unstable
   3 src/libcore/str/mod.rs: str_mut_extras
   4 src/libcore/char.rs: decode_utf8
   4 src/libcore/char.rs: fused
   4 src/libcore/cmp.rs: never_type_impls
   4 src/libcore/convert.rs: try_from
   5 src/libcore/cell.rs: coerce_unsized
   5 src/libcore/char.rs: char_escape_debug
   5 src/libcore/num/mod.rs: try_from
   5 src/libcore/ops.rs: placement_new_protocol
   5 src/libcore/ptr.rs: unique
   6 src/libcore/iter/range.rs: fused
   7 src/libcore/iter/mod.rs: trusted_len
   7 src/libcore/mem.rs: manually_drop
   7 src/libcore/str/mod.rs: fused
   8 src/libcore/hash/sip.rs: sip_hash_13
   9 src/libcore/ptr.rs: shared
  10 src/libcore/ops.rs: coerce_unsized
  10 src/libcore/slice/mod.rs: fused
  10 src/libcore/str/mod.rs: str_checked_slicing
  14 src/libcore/slice/mod.rs: slice_rsplit
  20 src/libcore/iter/mod.rs: fused

[SimonSapin]

@Mark-Simulacrum How did you make this list? It’s missing at least core_slice_ext, core_str_ext, and core_char_ext for the core::slice::SliceExt, core::str::StrExt, and core::char::CharExt traits, which is what this issue is about. They are re-exported from libcore’s prelude, which is different from libstd’s prelude.

[Mark-Simulacrum]

I can't find the command in my history right now for some reason. I guess I messed up with the ripgrep parameters, though. No need for the list now though, since you've provided it :).

[nagisa]

We certainly should move non-allocating inherent slice methods into libcore as inherent methods, and not the trait mess we’re currently in.

I’m fairly sure we could hack the compiler enough to allow multiple inherent impl blocks across the libcore and libcollections crates with some attribute or something.

[Razican]

Hello, I'm seeing that the core_float feature redirects here. I found it out when trying to use f32::powi(). Why are float "power" methods not available in stable core? Do they need to allocate? Why?

[SimonSapin]

@alexcrichton Should core::num::Float be added to core::prelude::v1, following the same pattern as CharExt for example? This would make methods like powi available to no_std crates.

[alexcrichton]

In general yes, functionality stable in libstd is fine to ensure is available in libcore as well. Looking at the trait it also has a stable Bits associated constant though, which means the entire trait is probably not ready for stable reexportation.

[Razican]

I also see that for the cos(), sin(), sin_cos() and sqrt() functions in floats only use intrinsics readily available in core_intrinsics. Maybe those could be stabilized as well, right?

[alexcrichton]

Those are ones we'd specifically actually not want to stabilize as well because they require runtime support. Their definitions in libcore should likely be removed.

[michael-p]

So if one needs to use sin, cos etc on an embedded device (with implementations provided by libc/libm) one has to use core::intrinsics::sinf32 and friends, right? Or is there another (better) way of doing this, since core_intrinsics is probably never going to be stable? (meaning using trigonometric functions in the embedded world will never be stable)

[Razican]

I was thinking on porting parts of libm to Rust using corrode or something similar, since I also would like to have atan(), asin() and acos() too, and they use cmath in the standard library. I still don't know if I could make them work without heap allocation, though.

I ported most of some code to use core::intrinsics::sinf32 and friends, but @alexcrichton said they should likely be removed, so it's probably not a good idea to depend on them. I didn't try to compile them to bare metal, even though they compiled fine using #[no_std].

I haven't started any work on sqrt().

[alexcrichton]

@Razican for sure yeah it's useful to have in libcore but it should be explicitly improted. Something like core::intrinsics::sinf32 just calls sin, so that's why it's not exported.