Tracking issue for f32/f64 support in libcore

[alexcrichton]

This issue is largely targeted at tracking the state of core_float in libcore, but it raises the question of how much floating point support should be in libcore. Right now we don't explicitly depend on many external functions, but a number of functions are exposed as bindings to LLVM intrinsics. We do depend on symbols like fmod and fmodf for floating point modulus. Almost all LLVM intrinsics end up getting lowered to function calls to known symbols as well.

As a result, supporting this functionality in libcore chips away at the principle of a "0-dependency library" (see #27200). We may wish to move all this functionality from libcore over to the standard library instead. This may raise questions about support for formatting floating point numbers as well, but it's something that will largely just fall out of an implementation.

[hanna-kruppe]

Is there a reason to move formatting support out of core, beyond "it may require float intrinsics that will be moved out of core"? Because AFAIK the current code doesn't require anything like that, and I see no reason why it should require that in the future. Same goes for parsing.

[alexcrichton]

Oh yeah if it doesn't actually require any intrinsics then it's totally fine to leave in core, it's only at most a maybe if it uses an intrinsic, and even then I think we'll still leave it in core and just say "if you use this please define the symbol".

[bluss]

Substring search is in libcore; in the long run I'd like to improve it with for example SSE4.2 features where available.

[alexcrichton]

Nominating for stabilization in 1.5, now that we've landed #27823 we only depend on libm where absolutely necessary, and otherwise the stabilization of this trait should easily match what's stable in libstd already.

[alexcrichton]

This issue is entering its cycle-long final comment period for stabilization in 1.5.

We can add in more functionality to libcore over time if possible, but otherwise there should only be external dependencies on fmod and fmodf now in libcore.

[eefriedman]

Does the final comment period cover the Float trait? I'm pretty sure we don't ever want to stabilize that.

[alexcrichton]

It was the intention that this does indeed cover the Float trait, but it was also intended that the trait would at least be named FloatExt and perhaps even F32Ext and F64Ext. The intention was to mirror the stability of the standard library as well (e.g. not mark everything as auto-stable).

It appears that this wasn't changed, however, so this may miss this FCP for a later date.

[alexcrichton]

This has largely been mitigated by #27823, so I'm going to close this in favor of #27701.