Front page | perl.perl5.porters |
Postings from February 2022
On Thu, Feb 24, 2022 at 12:48 AM Darren Duncan <darren@darrenduncan.net> wrote: > On 2022-02-23 8:40 p.m., demerphq wrote: > > To paraphrase what you said above: I hear that there is some wish that > Perl had > > immutable strings. But it doesn't, and making new functions that > correspond to > > that forlorn hope violates all existing precedents and will only sow > confusion. > > Depending what "immutable strings" means, Perl DOES have them, because it > is a > regular scalar type that is not a reference type. > > As far as I'm concerned, the main badness for "mutable strings" is when > this > happens: > > my $s1 = "abc"; > my $s2 = $s1; > # do something that modifies the string in $s2 > # now $s1 has also been modified > > The above description is the case when $s1 was assigned some kind of > reference > type like an arrayref. But it isn't the case for an ordinary Perl string. > > For existing cases, does "chomp($s2)" or "$s2 =~ s///" etc REALLY modify > the > string itself, or does it just derive a new string and assign it to $s2? > From > the user's perspective I would say make new and assign is what actually > happens. > > So unless I'm wrong about how things work, Perl's strings ARE immutable, > and > what we have here is functions or operations that assign a result to the > variable they got their input from, which is not the same thing. > Scalar values are passed as an alias, so even when passing them around functions, mutating the string can (and quite often does) cause action at a distance. More commonly it occurs somewhere within the same function, or via a superglobal like $_. -DanThread Previous