New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add (limited) CTFE #322

Closed
nrc opened this Issue Sep 25, 2014 · 14 comments

Comments

Projects
None yet
@nrc
Member

nrc commented Sep 25, 2014

See #253 for a limited form of CTFE. We can use this issue to track a more complete form too.

@archshift

This comment has been minimized.

Show comment
Hide comment
@archshift

archshift Feb 16, 2016

Contributor

Can we revisit this discussion now that the 1.0 launch craze has passed?

Contributor

archshift commented Feb 16, 2016

Can we revisit this discussion now that the 1.0 launch craze has passed?

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Feb 16, 2016

Member

This seems like it's covered by the const fn work?

Member

sfackler commented Feb 16, 2016

This seems like it's covered by the const fn work?

@ticki

This comment has been minimized.

Show comment
Hide comment
@ticki

ticki Feb 16, 2016

Contributor

@sfackler Yeah, but const fn needs to be able to perform non-trivial functionality. For this to be done, we need const fn methods in traits and impls of traits.

Contributor

ticki commented Feb 16, 2016

@sfackler Yeah, but const fn needs to be able to perform non-trivial functionality. For this to be done, we need const fn methods in traits and impls of traits.

@ranma42

This comment has been minimized.

Show comment
Hide comment
@ranma42

ranma42 Feb 16, 2016

Contributor

Moreover the functions mentioned in #253 (size_of, min_align_of, pref_align_of), just like several other intrinsic-based functions, are not yet const.

Contributor

ranma42 commented Feb 16, 2016

Moreover the functions mentioned in #253 (size_of, min_align_of, pref_align_of), just like several other intrinsic-based functions, are not yet const.

@JinShil

This comment has been minimized.

Show comment
Hide comment
@JinShil

JinShil Nov 26, 2016

Contributor

I was quite surprised that the following code does not compile:

const CONDITION: bool = true;
const RESULT: u8 = if CONDITION { 1 } else { 0 };

This seems like it's covered by the const fn work?

I thought so too, but this doesn't compile:

#![feature(const_fn)]
pub struct BitField (u8, u8);
impl BitField
{
    const fn get_ms_bit_index(&self) -> u8 {
        if self.0 > self.1 { self.0 } else { self.1 }
    }
}
Contributor

JinShil commented Nov 26, 2016

I was quite surprised that the following code does not compile:

const CONDITION: bool = true;
const RESULT: u8 = if CONDITION { 1 } else { 0 };

This seems like it's covered by the const fn work?

I thought so too, but this doesn't compile:

#![feature(const_fn)]
pub struct BitField (u8, u8);
impl BitField
{
    const fn get_ms_bit_index(&self) -> u8 {
        if self.0 > self.1 { self.0 } else { self.1 }
    }
}
@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Nov 26, 2016

Contributor

Its in progress work. See the “postponed” label on the right hand side.

Contributor

nagisa commented Nov 26, 2016

Its in progress work. See the “postponed” label on the right hand side.

@petrochenkov

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Nov 26, 2016

Contributor

@JinShil
The workaround is to use an array of two elements:

const CONDITION: usize = 1; // true as usize
const RESULT: u8 = [0, 1][CONDITION];
Contributor

petrochenkov commented Nov 26, 2016

@JinShil
The workaround is to use an array of two elements:

const CONDITION: usize = 1; // true as usize
const RESULT: u8 = [0, 1][CONDITION];
@petrochenkov

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Nov 26, 2016

Contributor

The lack of if in constant expressions is a pretty serious deficiency, its C analogue ?: works even in preprocessor constant expressions. And C code does rely on this property of :?, this creates problems when porting.

Contributor

petrochenkov commented Nov 26, 2016

The lack of if in constant expressions is a pretty serious deficiency, its C analogue ?: works even in preprocessor constant expressions. And C code does rely on this property of :?, this creates problems when porting.

@Amanieu

This comment has been minimized.

Show comment
Hide comment
@Amanieu

Amanieu Nov 26, 2016

Contributor

If we allow if in constant expressions then it would make sense to allow match as well.

Contributor

Amanieu commented Nov 26, 2016

If we allow if in constant expressions then it would make sense to allow match as well.

@kevincox

This comment has been minimized.

Show comment
Hide comment
@kevincox

kevincox Nov 26, 2016

Both if and match sound reasonable to me.

kevincox commented Nov 26, 2016

Both if and match sound reasonable to me.

@frewsxcv

This comment has been minimized.

Show comment
Hide comment
@frewsxcv

frewsxcv May 5, 2017

Member

Does anyone know what the status of conditionals within const fns are? Is it blocked on something in particular? An RFC? Implementation?

Member

frewsxcv commented May 5, 2017

Does anyone know what the status of conditionals within const fns are? Is it blocked on something in particular? An RFC? Implementation?

@BenWiederhake

This comment has been minimized.

Show comment
Hide comment
@BenWiederhake

BenWiederhake Jun 25, 2017

Found this RFC after creating rust-lang/rust#42906 . What can I do to help? What's the next step?

BenWiederhake commented Jun 25, 2017

Found this RFC after creating rust-lang/rust#42906 . What can I do to help? What's the next step?

@eddyb

This comment has been minimized.

Show comment
Hide comment
Member

eddyb commented Jun 25, 2017

@petrochenkov

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Jan 30, 2018

Contributor

MIRI is merged into rustc and is will be used for all const evaluation soon (rust-lang/rust#46882), and size_of is already constexpr, so I don't think there's value in keeping this issue open.

Contributor

petrochenkov commented Jan 30, 2018

MIRI is merged into rustc and is will be used for all const evaluation soon (rust-lang/rust#46882), and size_of is already constexpr, so I don't think there's value in keeping this issue open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment