in reply to Re^2: Shouldn't references be readonly? (updated)
in thread Shouldn't LITERAL references be readonly? (updated)

The whole discussion about "literals" is unfortunately only distracting

uh, I didn't bring up literals at all. It's an ambiguous word which may or may not include [4,5,6] depending on who you ask. It's useless to talk about literals.

You asked why it wasn't like "TEST", 42 and undef, and I told you why.

If you want to ask a different question now, fine.

map { ++$_ } [1,2,3] should throw an error

After all the fuss you made about inconsistency when you thought it wasn't consistent, you now want to make it inconsistent?

No, assigning a number to a scalar that previously contained a reference is odd, but it shouldn't be an error.

Replies are listed 'Best First'.
Re^4: Shouldn't references be readonly? (updated)
by ikegami (Patriarch) on Aug 07, 2020 at 01:19 UTC

    Ok, I'd like to contradict myself.

    I'd actually be ok with making "unassigned" scalars read-only. That includes [...], $x.$y, <>, etc.

    It might have performance implications, but they should be extremely tiny.

    It would break some code (such as my @lines = map { chomp; } <>;), but I think the benefits might be larger.

      > It would break some code

      I think if it comes to simple scalar types like strings this would result in a migration nightmare.

      Hence I wouldn't include the cases like $x.$y, <>, etc at least by default.

      Refs on the other hand should be immutable, because the result is always junk.

      But I doubt we have the resources to implement that anyway.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

        @a = map { $_ = 3; } [];

        is no more or less junk than

        @a = map { $_ = 3; } $x.$y;

        Are you therefore talking about [] + 1? Making the reference read-only is not going to catch that.