Stream: general

Topic: const fn wishlist


nagisa (Sep 16 2019 at 21:17, on Zulip):

@oli a crazy request: replace build.rs with const fn.

nagisa (Sep 16 2019 at 21:21, on Zulip):

/me thinks… we would need to reimplement gcc in const-fn-rust.

RalfJ (Sep 16 2019 at 21:22, on Zulip):

have fun implementing gcc without using conditionals :D

nagisa (Sep 16 2019 at 21:22, on Zulip):

@RalfJ well the context is https://www.youtube.com/watch?v=wkXNm_qo8aY which I watched mostly because I like oli’s way of saying things.

nagisa (Sep 16 2019 at 21:23, on Zulip):

@RalfJ also inline assembly replaced by a const fn would be dope :D

RalfJ (Sep 16 2019 at 21:24, on Zulip):

I just searched for RustConf 2019 talks earlier today and couldnt find any... odd^^

nagisa (Sep 16 2019 at 21:24, on Zulip):

Specifically Oli said y'all are working on it and was looking for things that we want to work.

RalfJ (Sep 16 2019 at 21:24, on Zulip):

ah, published today. well then.^^

QuietMisdreavus (Sep 16 2019 at 21:24, on Zulip):

the talk recordings were only posted today, lol

centril (Sep 16 2019 at 21:42, on Zulip):

@nagisa throw up an issue in https://github.com/rust-lang/rust/issues/57563 or something

Jake Goulding (Sep 17 2019 at 01:19, on Zulip):

gcc without using conditionals

This is the True Deterministic Build

gnzlbg (Sep 17 2019 at 09:49, on Zulip):

@oli cool talk

oli (Sep 17 2019 at 09:51, on Zulip):

thx

oli (Sep 17 2019 at 09:51, on Zulip):

it was a lot of fun to hold

Wesley Wiser (Sep 17 2019 at 09:54, on Zulip):

Just watched it last night. Compile time serde is a really neat idea!

gnzlbg (Sep 17 2019 at 10:55, on Zulip):

@oli I have a small prototype of packed_simd that uses the new repr(simd) [T; N], but needs to use -Zunleash-the-miri-inside-of-you :/

gnzlbg (Sep 17 2019 at 10:57, on Zulip):

the feature is quite fun to play with

oli (Sep 17 2019 at 11:57, on Zulip):

@gnzlbg what's the blocker for you? loops or conditionals?

gnzlbg (Sep 17 2019 at 11:57, on Zulip):

generics

gnzlbg (Sep 17 2019 at 11:58, on Zulip):

I want to be able to write:

impl<T: SomeTrait, const N:usize> for [T; N] {
    const fn splat(x: SomeTrait::Input) -> Self {
        [x.map(); N]
    }
}
oli (Sep 17 2019 at 11:58, on Zulip):

that just needs #![feature(const_fn)]

oli (Sep 17 2019 at 11:59, on Zulip):

oh

oli (Sep 17 2019 at 11:59, on Zulip):

wait that works!?!?

gnzlbg (Sep 17 2019 at 11:59, on Zulip):

No it doesn't

gnzlbg (Sep 17 2019 at 11:59, on Zulip):

That's commented out for me right now

oli (Sep 17 2019 at 11:59, on Zulip):

"works" with -Zunleash-the-miri-inside-of-you?

oli (Sep 17 2019 at 11:59, on Zulip):

it shouldn't

oli (Sep 17 2019 at 12:00, on Zulip):

you need https://github.com/rust-lang/rfcs/pull/2632 for that

gnzlbg (Sep 17 2019 at 12:00, on Zulip):

I tried using an associated const MAP: fn(Self::Input) -> Self

oli (Sep 17 2019 at 12:00, on Zulip):

that won't work either :slight_smile:

gnzlbg (Sep 17 2019 at 12:00, on Zulip):

to do pointer dispatch

gnzlbg (Sep 17 2019 at 12:00, on Zulip):

but it did not work

gnzlbg (Sep 17 2019 at 12:00, on Zulip):

yeah

oli (Sep 17 2019 at 12:00, on Zulip):

wait... that may work

gnzlbg (Sep 17 2019 at 12:01, on Zulip):

it did not work for me

oli (Sep 17 2019 at 12:01, on Zulip):

is the function you turn into a function pointer a const fn?

gnzlbg (Sep 17 2019 at 12:01, on Zulip):

yes, but I couldn't specify it in the trait as const MAP: const fn(...)

oli (Sep 17 2019 at 12:01, on Zulip):

that's irrelevant I thought

oli (Sep 17 2019 at 12:01, on Zulip):

what's the error you're getting

gnzlbg (Sep 17 2019 at 12:01, on Zulip):

let me uncomment that and try

gnzlbg (Sep 17 2019 at 12:01, on Zulip):

let's move this to another stream, and I have a pizza in the oven

oli (Sep 17 2019 at 12:02, on Zulip):

as long as the function is defined as const fn, -Zunleash-the-miri-inside-of-you should work

oli (Sep 17 2019 at 12:10, on Zulip):

yea, function pointers work: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f80d7c63f2cf2b91106a91860e80d219

oli (Sep 17 2019 at 12:10, on Zulip):

I love that I can test this on stable :D

RalfJ (Sep 18 2019 at 09:19, on Zulip):

I love that I can test this on stable :D

that's the fib thing from your talk, right? Isn't it a bug that we even attempt to compute this?^^

oli (Sep 18 2019 at 09:36, on Zulip):

don't mess with my pretties

oli (Sep 18 2019 at 09:37, on Zulip):

but yes it's a bug

oli (Sep 18 2019 at 09:37, on Zulip):

though I'm not sure how fixable... something something typeck queries

gnzlbg (Sep 22 2019 at 09:40, on Zulip):

more to the wishlist, I needed a is_const_eval intrinsic for packed_simd

gnzlbg (Sep 22 2019 at 10:25, on Zulip):

depending on the target we might want to dispatch to a dynamically-linked libmvec, and each libmvec has different symbol / function names

gnzlbg (Sep 22 2019 at 10:25, on Zulip):

as well as precision, etc.

gnzlbg (Sep 22 2019 at 10:26, on Zulip):

we also have lots of workarounds for llvm codegen bugs, that call different llvm.intrinsics instead of portable rustc intrinsics

gnzlbg (Sep 22 2019 at 10:26, on Zulip):

on the different architectures

gnzlbg (Sep 22 2019 at 10:26, on Zulip):

in constant evaluation none of that makes sense doing

Lokathor (Sep 22 2019 at 20:07, on Zulip):

i want const SIMD filling

Lokathor (Sep 22 2019 at 20:07, on Zulip):

I don't need the evaluation const, but i want to be able to declare PIx4 as a 128 bit const for example

gnzlbg (Sep 23 2019 at 06:06, on Zulip):

You can already do that

Lokathor (Sep 25 2019 at 03:11, on Zulip):

example code?

gnzlbg (Sep 25 2019 at 06:31, on Zulip):

You can use an union

gnzlbg (Sep 25 2019 at 14:15, on Zulip):

@Lokathor this works on stable: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2743cb6a0f85f4992975eab5bffedc64

Lokathor (Sep 25 2019 at 16:17, on Zulip):

That's extremely sub-optimal

Lokathor (Sep 25 2019 at 16:17, on Zulip):

I agree that it works, but it's not fit for using in a lib that you want end users to use

gnzlbg (Sep 25 2019 at 16:27, on Zulip):

you can write a macro that does that

gnzlbg (Sep 25 2019 at 16:30, on Zulip):

does your lib return core::arch types and does it require your users to put those in consts ?

Lokathor (Sep 25 2019 at 16:39, on Zulip):

I'd like to have pub const Name: Newtype Wrapper = (whatever);

Lokathor (Sep 25 2019 at 16:40, on Zulip):

i guess it works out, i can just put the newtype into the union too

gnzlbg (Sep 25 2019 at 17:48, on Zulip):

what's "whatever" ?

gnzlbg (Sep 25 2019 at 17:48, on Zulip):

(is kind of important)

gnzlbg (Sep 25 2019 at 18:14, on Zulip):

If you want something like NewtypeWrapper::new(...) in the rhs, then I don't think there is a way to do that

gnzlbg (Sep 25 2019 at 18:14, on Zulip):

on stable at least

gnzlbg (Sep 25 2019 at 18:14, on Zulip):

on nightly it is easy if you enable unions in const fn

gnzlbg (Sep 25 2019 at 18:14, on Zulip):

on stable the only workaround is a macro

Lokathor (Sep 25 2019 at 21:53, on Zulip):

yeah it's a new method call, but using unions that call can be made const

Lokathor (Oct 04 2019 at 02:03, on Zulip):

oh wait, it can't be a const fn with the union trick, i see now what you mean.

drat.

nagisa (Nov 14 2019 at 00:25, on Zulip):

@oli const fn OsStr::new!

oli (Nov 14 2019 at 12:23, on Zulip):

That requires https://github.com/rust-lang/rfcs/pull/2632 because OsStr::new has trait bounds

Lokathor (Nov 15 2019 at 05:15, on Zulip):

core::mem::zeroed, did we say that one yet?

I hope you're keeping track of all these in an issue or something oli ;3

oli (Nov 15 2019 at 13:41, on Zulip):

I don't think we're doing mem::zeroed. Instead we'll do MaybeUninit::zeroed

Lokathor (Nov 15 2019 at 15:28, on Zulip):

Well that is a distressing and poor decision :(

Jake Goulding (Nov 15 2019 at 15:34, on Zulip):

Why? It will encourage people to use the better supported version.

Jake Goulding (Nov 15 2019 at 15:34, on Zulip):

Thinking of other deprecated functions, will thread::sleep be const? :-)

oli (Nov 15 2019 at 15:39, on Zulip):

:upside_down: uh sure we could do that

Jake Goulding (Nov 15 2019 at 15:55, on Zulip):

Nice. Then I can gradually speed up the compile times of my code.

oli (Nov 15 2019 at 15:59, on Zulip):

nah, it won't do a thing

simulacrum (Nov 15 2019 at 16:06, on Zulip):

There's no point in making the old version const fn because to use that you'd need to be on a new compiler which has MaybeUninit already anyway right?

oli (Nov 15 2019 at 16:10, on Zulip):

yes

oli (Nov 15 2019 at 16:11, on Zulip):

not giving features to deprecated things will help adoption of the replacement, too

Amanieu (Nov 15 2019 at 18:27, on Zulip):

We didn't deprecate mem::zeroed though, only mem::uninitialized.

Amanieu (Nov 15 2019 at 18:27, on Zulip):

Because mem::zeroed has valid use cases with FFI.

simulacrum (Nov 15 2019 at 18:28, on Zulip):

hm, but so does uninitialized, right? My impression was that the two are essentially equivalent...

simulacrum (Nov 15 2019 at 18:28, on Zulip):

Maybe I misunderstood

Amanieu (Nov 15 2019 at 18:36, on Zulip):

Basically *val = mem::zeroed(); is equivalent to memset(&val, 0, sizeof(val));

simulacrum (Nov 15 2019 at 18:38, on Zulip):

sure, I understand that, but I'd expect us to push users towards MaybeUninit::zeroed().assume_init(). I guess that's not really better in any way.

simulacrum (Nov 15 2019 at 18:39, on Zulip):

though arguably you should pass the ptr into FFI if you can rather than the zeroed struct (and then afterwards assume_init())

Lokathor (Nov 15 2019 at 20:29, on Zulip):

that's way longer to type for no actual gain in clarity. the argument could be made that clarity is significantly reduced in fact

Lokathor (Nov 15 2019 at 20:31, on Zulip):

essentially any C struct from FFI is safe to be zeroed (in the "data validity" sense), and you often set fields of the structure on your side of things before passing the pointer to FFI

simulacrum (Nov 15 2019 at 20:32, on Zulip):

yeah, that's true

simulacrum (Nov 15 2019 at 20:32, on Zulip):

though it is sometimes convenient to have references and such in FFI layers which can't then be zeroed

Lokathor (Nov 15 2019 at 20:33, on Zulip):

that danger is already being fixed: https://github.com/rust-lang/rust/pull/66059

Lokathor (Nov 15 2019 at 20:34, on Zulip):

i wish that rust language people would please stop thinking that core::mem::zeroed is somehow not good to use

Lokathor (Nov 15 2019 at 20:35, on Zulip):

it is a better API than MaybeUninit::zeroed().assume_init()

Lokathor (Nov 15 2019 at 20:35, on Zulip):

just because it is less verbose and you see the point of the expression more easily when reading the page

oli (Nov 15 2019 at 20:37, on Zulip):

you know this is zulip and you can fork a thread instead of hijacking the const fn wishlist for hashing out different opinions on things ;)

simulacrum (Nov 15 2019 at 20:37, on Zulip):

/me had thought this was just about zeroed :)

Lokathor (Nov 15 2019 at 20:38, on Zulip):

ah right, is there a way to fork a thread after the fact?

Lokathor (Nov 15 2019 at 20:38, on Zulip):

i did not mean to clog up the list

oli (Nov 15 2019 at 20:38, on Zulip):

trying to figure that out right now, I've seen ppl do it before

Jake Goulding (Nov 15 2019 at 21:55, on Zulip):

Thinking of other deprecated functions, will thread::sleep be const? :-)

nah, it won't do a thing

@oli why wouldn't it? Or do you just mean you'd deliberately make it so that it was a no-op?

simulacrum (Nov 15 2019 at 21:59, on Zulip):

I expect defining 'time' as a thing in const fn is awkward

centril (Nov 15 2019 at 22:33, on Zulip):

@Jake Goulding building a model of concurrency compatible with deterministic execution is going to be a fun project :slight_smile:

RalfJ (Nov 16 2019 at 09:23, on Zulip):

core::mem::zeroed, did we say that one yet?

I hope you're keeping track of all these in an issue or something oli ;3

we have an issue or at least discussions specifically about zeroed somewhere

RalfJ (Nov 16 2019 at 09:24, on Zulip):

doing this "right" is blocked on &mut-in-const

Last update: Nov 20 2019 at 13:25UTC