> On Aug 16, 2021, at 8:00 AM, Graham Knop <haarg@haarg.org> wrote: > > After thinking about this again, I had another idea. > > The reason implying 'use utf8' is a problem is because of the impact > it has on string semantics. Maybe we can just have it not impact > string semantics. Make 'use v5.36.0;' decode the source as UTF-8, but > store string literals as byte strings rather than characters. The > strings would still be required to be UTF-8 encoded, but would be > stored with the utf8 flag off. This would allow using UTF-8 encoded > content in comments, Pod, or even in function names, but would not > create the confusion with strings and IO. I thought of this sometime back, but more in the context of adding flexibility to utf8.pm: { use utf8 decode => 'no_strings'; # What Graham envisions my $foo = "é"; # 2 code points } { use utf8 decode => 'all'; # status quo my $foo = "é"; # 1 code point } I personally would think decode=no_strings could be added to the feature bundle with little trouble. The use case for leaving strings undecoded doesn’t seem to apply for things besides strings. -FThread Previous | Thread Next