A decision needs to be made regarding handling of undef as nil.
There is agreement that it should be handled as a nil value everywhere except one case; when setting an attribute value.
Currently setting undef as an attribute value has the meaning "do not set this attribute" (as opposed to "set this attribute to nil") - which has the effect of selecting the default value at the receiving end (the define, or class).
While this is probably a reasonable default (what users expect), it poses one problem - it is not possible to override a default value with nil. For Arrays, Hashes and String an empty object can be passed, but for numbers this is not possible.
- attribute assignment of nil == 'do not set'
- add operator that sets it to nil (e.g. !>, !=>)
- add operator if/when needed since this corner case is rare
- attribute assignment of nil == 'assign nil', add operator that means 'do not set' (e.g. ?=>)
The choice "attribute assignment of nil == 'do not set' and add operator later if this is a problem' seems to be best compromise.