@WG-const-eval Which CTFE-related features would you like to see worked on going forward? Here are a few off the top of my head.
Droptypes in constants (#66753)
There's also some tasks that don't involve design work like:
It would be cool to know what people want to prioritize next year.
@Christian Poveda is looking at mut references I believe
I don't think we can even start on heap without at least an e-RFC
Christian Poveda is looking at mut references I believe
yes we have a feature gate for that now
&mut is pretty close, although this is a bit concerning:
It's probably unsound, so I presume that's what @ecstatic-morse means
ROFL yea, constants are bad
The others would all require RFCs, depending on how narrowly we want to address #66753
Maybe we need
ConstSafe even before heap
But I recall that
const trait methods have had a lot of design work and are (maybe?) pretty close
If I could pick one feature from the list above, it would probably be that one. Even though it's a ton of work and a pretty profound change to the language
Yes, I have an RFC and the status is that T-lang discussed it and is basically fine with it being an experimental feature, but I'm waiting for public confirmation of this before doing any work on it. Otherwise an open PR would put pressure on the RFC being handled faster
I'll take a look at this
Maybe we could implement
?const Trait first, because that is the behaviour of current trait bounds with
@Christian Poveda read the const heap tracking issue
It has similar problems
that's funny, I wanted to get involved with const heap :P
There's no real difference between
&mut T if it's in a global thing
I think the current RFC process is lacking when it comes to really big changes like
const trait methods. It's better for small changes that don't need a lot of experimentation. The process laid out in nikomatsakis' blog post would be a much better fit.
Ooh new RFC process blog posts. It's been a while
Can anyone think of an obvious feature/work-item that I've missed?
I guess there's always "pay down technical debt", which I've been doing a bit of in the const-checking arena.
But that isn't very inspiring XD
A bit is a bit of an understatement. That's some amazing cleanup duty you've taken up
yeah code janitoring is underrated
I'll think about what cool features are still missing in const eval. I think you covered the big ones. For now I'm going to bed. Oh one thought that I just had was side effects like emitting warnings on purpose or emitting artifacts.
Also type declarations by const eval emitting a TyLayout equivalent
So what proc macros did for codegen, const eval could do for type declarations
(Including their layout "obviously")
Really this time
Yeah artifacts would be very cool. Perfect hash functions with no build script. Goodnight! Sorry for nerd sniping.
Why do perfect hash functions need artifacts? I thought they were for use inside a program, so all you'd need to do is compute the hash table... oh and the hash function parameters. Or do we need to generate an entire function for performance reasons?
Maybe we can just fill in associated constants and make a single generic function that is then optimized to the perfect hash function
/me knows nothing about PHF
static: &mut i32 a data race waiting to happen?
It's basically a
static mut with no unsafe required
&mut isn't copyable, so maybe that helps?
Whoops wrong thread
There's some more advanced perfect hash function generators that vary the class of hash function based on the input. You're right that the vast majority wouldn't require artifacts. It was the first thing that popped into my head.
I might actually try to implement a non-proc-macro PHF generator. Seems kind of fun!
You can vary the hash function class by "indexing". Implement the different classes by making them traits on arrays. Each class is a different array length. Choose the algorithm via the index
@ecstatic-morse we have a yellow light on implementing the const trait bounds RFC
Even with the RFC still open, an unstable experiment is now permitted
Cool! I'm happy to help implement, although it will not touch any code that I'm familiar with. Also I won't have much time until after the holidays. I'm mobile only for the next few days XD. I'll reread the draft RFC
yea no rush, if you want we can make an impl brainstorm meeting
I have ideas how to get there in small steps, which should also help not requiring you to modify the entire compiler everyhwere
Sounds good. I'll be back at full availability after Christmas on the 30th. Anytime after that would be fine for a meeting.
:+1: ok, I'm not sure how available I am between 30th and 7th
we'll find sth
I'm happy to review the parser changes :slight_smile:
@oli I implemented a perfect hash function generator that runs entirely during const-eval. It's not very robust (it's a heuristically guided random search loosely based on gperf), but my intention was to get an idea of the most painful parts of writing complex code in a const context.
(computing a PHF for the set of rust keywords takes around a second and completes just after the loop detector is triggered)
The experience reaffirmed my belief that calling trait methods in const contexts is the next major roadblock. Writing code without for-loops or range-based/custom indexing is not fun.
I ended up using a stack-only dynamic array a lot. Constification of
MaybeUninit would allow pretty much all of staticvec to be
const if const trait impls were implemented. I ended up rolling my own version that required
T: Copy, needed an initial value and still had UB during initialization.
The other concern I have is the lack of
expect. I think it is likely that library authors will resort to extensions like
fn unwrap<T: Copy>(x: Option<T>) -> T. However, as you pointed out on that issue, I doubt there will ever be a way to implement
const Option::<T>::unwrap for all
Twithout awful hacks.
In fact, the need for these two methods was so acute that I am now in favor of doing a
mem::forget-style hack to make them
const fn on
Result. Others will no doubt disagree.
? operator would also be desirable, although I did not run into this quite as much, and it would require the same hacks as for
unwrap as well as const trait impls.