const fn version does have a const cycle

[Pzixel]

Current master branch is unable to compile following snippet:

use utf16_lit::*;

const UTF8: &str = "cycle!";

fn main() {
    let _ = &utf16!(UTF8);
}

It happens because the first variable is obfuscated when UTF8, UTF16 and LEN aren't and are quite likely to be in the macros scope.

I suggest either obfuscate them as well or implement the code without relying on global constants. I'm not sure macros should declare any constants, it could just execute the input and return it, not sure why it works this way now.

P.S. next_code_point should probably be unsafe because it does some assumptions about input or merely accept &str instead of &[u8] - I doubt there would be any overhead because of doing that, you can &str -> &str just as easy as you do with &[u8] -> &[u8]

[Lokathor]

You cannot &str to &str in a const fn (yet).

Also the constants declared aren't global, they're scoped to the block that's inner to the macro invocation. They don't bleed out after the block concludes.

But I'll look in to the rest.

[Pzixel]

Also the constants declared aren't global, they're scoped to the block that's inner to the macro invocation. They don't bleed out after the block concludes.

Right but maybe it worth making them just lets? I'm not very familiar with const fn's and its limitations, I've just found out that some seemingly valid code may fail to compile.

[Lokathor]

a let binding can't be the input to the type of a const, and we need to make an output buffer to re-encode the data to

[Pzixel]

All right then, thanks for explanation. Wish you my best luck 😃