Re^2: Shouldn't references be readonly? (updated)

[LanX]

my main point is that things like this

 map { ++$_ } [1,2,3]

should throw an error, because the mutation of a reference itself doesn't make any sense.

And I was asking if there is a reason why they don't.

The whole discussion about "literals" is unfortunately only distracting,

(though Wikipedia is on my side: Literal (computer programming): "a notation for representing a fixed value in source code" but I don't wanna continue this.

NB: fixed doesn't mean (compile-time) constant. It means not variable)

[ikegami]

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.

[ikegami]

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.

[LanX]

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