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

Most functions could be const #56

Open
PvdBerg1998 opened this issue Mar 22, 2019 · 4 comments
Open

Most functions could be const #56

PvdBerg1998 opened this issue Mar 22, 2019 · 4 comments
Assignees
Labels

Comments

@PvdBerg1998
Copy link

See title. I'm not an expert on what subset of const functions are stabilized yet, but I think a lot could already be const fn (think AsciiChar::as_byte).

@tormol
Copy link
Collaborator

tormol commented Mar 23, 2019

Many methods can, but it's not yet possible to convert from other types, and without those, making other methods const doesn't seem all that useful.

Creating AsciiChar from u8 or char requires transmute or match (but with 129 arms!).
Going from &str or &[u8] to &AsciiStr or back requires "dereferencing" raw pointers (or transmute).
Vec::new() surprisingly isn't const yet either, so AsciiString::new() cannot be const either.
While writing this i remembered reading about an union transmute trick, but it turns out that only works for constants, not const fns. ugh.

For many of the functions that can be made const, it isn't as simple as slapping const on them either.
For example AsciiChar::is_blank() has to be changed from self == AsciiChar::Space || self == AsciiChar::Tab to (self as u8 == b' ') | (self as u8 == b'\t').

For AsciiChar::as_byte() you can instead write as u8, and then you can use u8's .is_ascii_xxx() methods instead of AsciiChars.
Are there other methods that would still be useful to you as const fn even without converting from primitive types?
Thank you for opening an issue anyway, I had considered opening one as a note and to track what is possible.

@tormol
Copy link
Collaborator

tormol commented Aug 26, 2019

Most AsciiChar methods has been made const fn with version 1.0.0.
I figured out that a const fn AsciiChar::new() was possible by indexing into a constant array.

For AsciiStr and AsciiString everything above still holds, so I'm leaving this issue open until they can be created in const contexts.

  • AsciiChar::new()
  • AsciiStr::new()
  • AsciiString::new()

@JOE1994
Copy link
Contributor

JOE1994 commented Jun 10, 2020

Most AsciiChar methods has been made const fn with version 1.0.0.
I figured out that a const fn AsciiChar::new() was possible by indexing into a constant array.

For AsciiStr and AsciiString everything above still holds, so I'm leaving this issue open until they can be created in const contexts.

* [x]  `AsciiChar::new()`

* [ ]  `AsciiStr::new()`

* [ ]  `AsciiString::new()`

It seems that AsciiStr::new() no longer exists as of 1.0.0 🐈

@tormol
Copy link
Collaborator

tormol commented Jun 10, 2020

AsciiStr::new() was removed so that it can be added back as a const fn when possible without any backwards compatibility restrictions. So if that's possible now then feel free to add it!

tomprogrammer pushed a commit that referenced this issue Oct 11, 2020
Since 'Vec::new()' is already a const function,
there is no difference in generated MIR/ASM whether
'AsciiString::new()' is marked 'const' or not.
I saw issue #56 is waiting to mark this function as 'const',
and so this PR simply marks 'AsciiString::new()' as a const fn.

Thanks for reviewing this PR :)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants