develooper Front page | perl.perl5.porters | Postings from February 2022

Re: trim vs trimmed revisited

Thread Previous
Dan Book
February 24, 2022 05:52
Re: trim vs trimmed revisited
Message ID:
On Thu, Feb 24, 2022 at 12:48 AM Darren Duncan <>

> 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 $_.


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About