Front page | perl.perl5.porters |
Postings from February 2022
> On Feb 3, 2022, at 19:35, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: > > On Fri, Jan 28, 2022, at 9:53 PM, Leon Timmermans wrote: >> And I don't see that benefit. As far as I can tell, the argument is really more about ideological purity than any practical advantages. One of the two internal encodings of Perl is (non-strict) UTF-8, and almost any code dealing with this distinction will have to have knowledge of what encoding is being used. Calling it "wide" or "heavy" might have made sense if we could hide that, but that's exactly what we can't do. > > First: I don't have a strong opinion about any of this, as it's outside my general realm of concern. My tendency is to agree with Leon. > > I think UTF8 was a bad name. I think it has led to confusion, especially when it pokes its head into Perl space when people see "UTF8" in dump output, or learn that something means "the utf8 flag is set". I wish we had picked something else. > > Changing it now seems too late to fix the problem, but does introduce complications. > > All that said: I largely defer to the serious C code contributors to perl.git, of whom I am not one. As you say, though, this aspect of Perl’s internals leaks into Perl space with some frequency. Sometimes it’s because someone is ill-informed, but sometimes it’s legitimate. I don’t think the only stakeholders of note here are those who contribute substantially to Perl’s core. That said, thus far the only respondents on this thread seem to dislike the proposal. At this point I feel like I’ve made the case; if it’s not persuaded folks, then thanks for everyone’s consideration. -FGThread Previous | Thread Next