• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • interfaces
  • Reporter: tgautier
  • October 10, 2008
  • 0
  • Watchers: 1
  • December 16, 2011

Attachments

Description

Roots that are literals are supposed to be reassignable. Integer does not follow this pattern (and likely, others such as Byte, Character etc.)

Attached is repro code.

Comments

Tim Eck 2008-11-14

If we allow mutable non-primitive literals roots we need to consider if we all allow nulls. Normally roots cannot be set to null.

If we allow this it is crucial to have tests for it, nulls are always nasty buggers

Alex Miller 2008-11-14

Tim and I looked at this a bit. Currently, non-primitive literal roots are not mutable in the code (despite beliefs to the contrary). We’d be ok documenting this as expected behavior. I’d argue that primitive vs non-primitive is easier distinction for a user to make than tc literal vs non-tc-literal.

I talked to Taylor about it and he thought either all roots should be mutable or none. I suggested more the latter. The one use case I can picture where mutable roots is necessary is where you are clustering code you can’t change and need to make a field resettable. But I’m not aware that this has or is blocking any use case we know of, so it would have to be pretty rare.

So, Taylor suggested that maybe all roots should be immutable unless you set a per-root flag indicating a root should be mutable, and that would allow *any* root to be mutable (not just primitives or tc literals). That’s a much bigger change in allowed behavior.

I punt! I’m way over my time budget on thinking about this today. Would like to discuss more and define behavior/changes/tests in a major release.