Allow more `const fn`s in std

[F001]

Functions in std which could be evaluated in compile time should be qualified by const.

Such as:

fn size_of<T>() -> usize;
fn size_of_val<T: ?sized>(_: &T) -> usize;
fn type_name<T: ?sized>() -> &'static str;
fn type_id<T: ?Sized + 'static> () -> u64;
fn needs_drop<T>() -> bool;
......

I suppose they should be const fn. And there are more. Is it correct?

[steveklabnik]

In general, this is something that is desired, but until const fn is closer to becoming stable, has not been seriously investigated, as far as I know.

[oli-obk]

I think all of these require incremental compilation, as the compiler needs to generate those function monomorphizations through compiler magic, but cannot do so before it compiled the types these functions are called on.

[eddyb]

@oli-obk It's orthogonal to the "redo as little as possible" part of incremental recompilation. I suppose "on-demand" overlaps enough to count, but hasn't been an explicit part of the incremental recompilation effort so far.

[aidanhs]

This is partially fixed by rust-lang/rust#42859 ({size,align}_of).

[trissylegs]

Could size_of_val be const? I guess things like size_of_val("boop") is const, but something like size_of_val::<Write>(some_boxed_writer) could be entirely runtime dependent. Like a boxed trait returned from a dynamically linked library.

[oli-obk]

I don't see why it shouldn't be const fn, but I don't know if the current const qualification system can handle it. I'd say we go to the low hanging fruit first

[trissylegs]

Just realized that it's not possible to make a runtime size dependent variable at compile time and therefor my point is moot.

[Centril]

Some of these are const now, so I'm closing this issue. I'd just create a thread on internals or file a PR if you want something to be const.