Skip to content

core::str::validations::next_code_point only accepts an Iterator<&u8> and can not accept an Iterator<u8> #95940

New issue

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

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

Already on GitHub? # to your account

Closed
mutantbob opened this issue Apr 11, 2022 · 3 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@mutantbob
Copy link

core::str::validations::next_code_point only accepts an Iterator<Item=&u8>. Unfortunately my code that needs to convert a byte stream to characters can only have an Iterator<Item=u8>. My specific use case is a string constant stored in progmem on an AVR (Arduino Uno), which requires special machine code to access, because the data exists in a separate address space from regular RAM. Other use cases could include streaming decompression or decryption. For now I have duplicated the code for next_code_point and embedded it in my application, but it would be nice to be able to use reuse the same code as the standard library.

@m-ou-se
Copy link
Member

m-ou-se commented Apr 13, 2022

The str_internals feature isn't meant to be used outside the standard library though. It doesn't even have a tracking issue.

If you think we should publicly expose such a function, we should discuss that proposal first.

@workingjubilee workingjubilee added the O-AVR Target: AVR processors (ATtiny, ATmega, etc.) label Mar 11, 2023
@saethlin saethlin added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-feature-request Category: A feature request, i.e: not implemented / a PR. and removed O-AVR Target: AVR processors (ATtiny, ATmega, etc.) labels Nov 20, 2023
@saethlin
Copy link
Member

This issue should be an API Change Proposal: https://github.com/rust-lang/libs-team/issues/new?assignees=&labels=api-change-proposal%2C+T-libs-api&projects=&template=api-change-proposal.md&title=%28My+API+Change+Proposal%29

The Rust issue tracker is generally not an effective place for starting discussions like this.

@Dylan-DPC
Copy link
Member

Closing this as this needs further discussion as a precursor before having this, and as mentioned in the pr linked above that this won't be accepted in the current state.

@Dylan-DPC Dylan-DPC closed this as not planned Won't fix, can't repro, duplicate, stale Jan 26, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants