Skip to content
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

Make Vec* methods const #4600

Closed
SUPERCILEX opened this issue Apr 26, 2022 · 11 comments
Closed

Make Vec* methods const #4600

SUPERCILEX opened this issue Apr 26, 2022 · 11 comments
Labels
A-Math Fundamental domain-agnostic mathematical operations C-Usability A targeted quality-of-life change that makes Bevy easier to use S-Blocked This cannot move forward until something else changes

Comments

@SUPERCILEX
Copy link
Contributor

What problem does this solve or what need does it fill?

I'd like to use Vec2 in a static declaration, but that's currently not possible.

What solution would you like?

Make Vec* methods const.

@SUPERCILEX SUPERCILEX added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Apr 26, 2022
@alice-i-cecile alice-i-cecile added S-Blocked This cannot move forward until something else changes C-Usability A targeted quality-of-life change that makes Bevy easier to use A-Math Fundamental domain-agnostic mathematical operations and removed C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Apr 26, 2022
@mockersf
Copy link
Member

This is not possible as Vec2 takes floats, and floats can't be const...

However, there is a macro const_vec2 that does that 🙂

@alice-i-cecile
Copy link
Member

Very reasonable. This is fundamentally blocked on float math being usable in const functions. Once that's in, I expect glam to rapidly migrate away from the mentioned macros.

@SUPERCILEX
Copy link
Contributor Author

Floats can't be const? TIL, though I guess that makes sense if a machine doesn't adhere to 754.

@SUPERCILEX
Copy link
Contributor Author

Actually, are you sure? This compiles just fine for me:

#[derive(Debug)]
struct Blah(f32, f32);

const BLAH: Blah = foo(1., 2.);

const fn foo(blah: f32, boo: f32) -> Blah {
    Blah(blah, boo)
}

pub fn use_it() {
    println!("{:?}", BLAH);
}

@SUPERCILEX
Copy link
Contributor Author

Related issue: bitshifter/glam-rs#76

@alice-i-cecile
Copy link
Member

const fn add_two() -> f32 {
  2. + 2.
}

This should fail to compile :( Here's the Rust issue: rust-lang/rust#57241

@SUPERCILEX
Copy link
Contributor Author

Hmmm, all I'd want is Vec2::new. Would it be reasonable to only allow construction? Or is there some extra magic happening that would prevent that?

@alice-i-cecile
Copy link
Member

That's ultimately a question for upstream. Maybe try it out in a glam fork?

@mockersf
Copy link
Member

Hmmm, all I'd want is Vec2::new.

If you just want that in a const context, the macro should work for you?

@SUPERCILEX
Copy link
Contributor Author

Good point, I guess I'll just use the macro though it seems weird to require that.

@alice-i-cecile
Copy link
Member

Closing out, although once the linked glam issue is resolved I'll be thrilled to be able to migrate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Math Fundamental domain-agnostic mathematical operations C-Usability A targeted quality-of-life change that makes Bevy easier to use S-Blocked This cannot move forward until something else changes
Projects
None yet
Development

No branches or pull requests

3 participants