Front page | perl.perl5.porters |
Postings from June 2022
On Fri, Jun 17, 2022, at 23:44, Darren Duncan wrote:
> On 2022-06-17 8:10 p.m., Ricardo Signes wrote:
> > On Fri, Jun 17, 2022, at 23:00, Darren Duncan wrote:
> >> 1. Treat the "yield true" feature like how we treat explicit declarations of
> >> file encoding, in that they are explicitly NOT lexical, and that having one
> >> anywhere in a file causes it to apply to the entire file, and/or it is only
> >> legal for the declaration to exist at the top level of a file and not inside any
> >> block.
> >
> > What are you referring to when you say "how we treat explicit declarations of
> > file encoding"?
>
> I refer to when we say "use utf8;" or "use encoding" etc.
Then you are mistaken, because "use utf8" is lexically scoped.
dinah:~$ cat length
use v5.36.0;
my $str1 = do { use utf8; "🙂" };
my $str2 = do { "🙂" };
say length $str1;
say length $str2;
dinah:~$ perl that-program-above
1
4
encoding.pm has been deprecated for nine years and fatal to use for seven. It's not a good thing to cite as example. But also, if you travel back in time and test it, its behavior is terrible and a good example for why "looks lexical, actually silently file-scoped" is a bad idea. It only affects the file *after it appears* in the file. This is one of the points we were going to pains to deal with when discussing source::encoding: how do you ensure whole-document coherency?
> So I'm saying that "yield_true" should be the same in the sense that while logically it COULD be lexical, there's in practice no good reason for it to be so, or if there was, it would be a very different feature than one designed to
> just remove the need for a "1;", that different feature would be mainly about altering how subroutines behave.
What am trying to do is not make it lexical, but to anticipate places where the user will be surprised and either make them not surprising or, at least, tell the user what happened.
--
rjbs
Thread Previous
|
Thread Next