develooper Front page | perl.perl5.porters | Postings from August 2021

Re: Pre-RFC: Rename SVf_UTF8 et al.

Thread Previous | Thread Next
From:
Felipe Gasper
Date:
August 20, 2021 13:19
Subject:
Re: Pre-RFC: Rename SVf_UTF8 et al.
Message ID:
5FBD287E-6889-4A2B-9BFE-3D772ECB548B@felipegasper.com

> On Aug 20, 2021, at 4:48 AM, Leon Timmermans <fawaka@gmail.com> wrote:
> 
> I would agree except that people not working on the internals also have to use these functions (for XS code), and thus misuse them because they think they're related to the logical contents of the string.
> 
> Any code dealing with strings on a C level will need to know if it is encoding in UTF8 or something different.

A bit off-topic, but worth bearing in mind: XS modules that merely interface between Perl and an external library (e.g., libcurl, libunbound) can avoid SvPV et al. in favour of the variants that preserve the abstraction.

It’s probably an overly simplistic ideal, but in theory it seems the only things that would need to care about what we currently call SVf_UTF8 are things that must read or manipulate Perl’s internals directly. Everything else -- even XS modules and embedding C applications -- can respect the abstraction.

> Changing the internal name to upgraded would make sense if we could change the internal implementation (e.g. to UTF16) without *everything* exploding.

That’s true, but the fact that the internal encoding can’t pragmatically change doesn’t invalidate the benefits of strengthening the abstraction, which include:

- Less confusion about what a “UTF-8 string” is: it’ll be clearer that upgraded/downgraded and (Perl-visible) UTF-8-ness are orthogonal qualities.

- More abstract terminology will discourage folks from trying to think too deeply about Perl’s internals.

-F
Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About