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

Re: "use v5.36.0" should imply ASCII source

Thread Previous | Thread Next
From:
Dan Book
Date:
August 7, 2021 21:53
Subject:
Re: "use v5.36.0" should imply ASCII source
Message ID:
CABMkAVXH0wyhGpZYCcWkF+wg6ihdvVjaY1BM7K28kS28OjA9EQ@mail.gmail.com
On Sat, Aug 7, 2021 at 5:44 PM Darren Duncan <darren@darrenduncan.net>
wrote:

> On 2021-08-07 8:55 a.m., Dan Book wrote:
> > On Sat, Aug 7, 2021 at 2:45 AM Darren Duncan wrote:
> >     Question:  Is there ever a real life scenario where a single source
> file is not
> >     entirely the same encoding?  Can you reasonably have a single file
> containing
> >     Perl code and POD where the Perl code is one character encoding and
> the POD is
> >     another one? -- Darren Duncan
> >
> > Yes. POD parsers and the perl interpreter do not read the same parts of
> the
> > file, ever. Thus they must each indicate to their corresponding parsers
> what
> > encoding they contain.
>
> The need to dual-declare is important to know but its not the question I
> asked.
>
> Is there ever a real life scenario where a single physical text file uses
> one
> character encoding for one range of octets in the file and a different
> character
> encoding for a different range of octets in the file.
>
> I'm not aware of any text editor that when asked to save a document to
> disk
> would not be using the same character encoding to write out the entire
> file.
>
> So I would think it would be a very contrived situation for a text file to
> exist
> physically that isn't all one encoding.
>
> And then the question is whether we would consider it valid for such a
> file to
> exist and that we would try to support it as a non-corrupted file.
>

It's not a matter of support. It just doesn't matter to the perl
interpreter what the encoding of POD is, and vice versa.

-Dan

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