It would be better to explain the motive. This is an appropriate code. ``` ruby { foo: 1 bar: 2 } ``` This is not a mistake, but it's a circuitous code. ``` ruby h = {} h[:foo] = 1 h[:bar] = 2 h ``` The gist of ...ursm (Keita Urashima)
I would like to offer that as I used a simple grep pattern, I could only find simple examples. I wanted to show that this is not as rare as it seems.ursm (Keita Urashima)
Eregon (Benoit Daloze) wrote in #note-8: > I don't think it's very frequent to need this to warrant a syntax change either. There are several Rails codes that can be improved with this feature. In my opinion, it is especially useful ...ursm (Keita Urashima)
I believe that the following two points will prevent the same problems as in the past: 1. Use a value that is never used (e.g., Hash::DROP) instead of nil. 2. Special treatment of “special value” only if the hash is constructed with ...ursm (Keita Urashima)
With the previous idea, I can't have both removing entries and returning nil depending on the condition. ``` ruby # If user.child? is true and user.parent is nil, I want parent_name: nil, but the entry is removed. { ?parent_name:...ursm (Keita Urashima)
nobu (Nobuyoshi Nakada) wrote in #note-1: > "A special value" doesn't feel like a good idea to me. Hmmm, does that mean we should extend the syntax? For example, something like this? ``` ruby { foo: 1, ?bar: nil } #=> {foo...ursm (Keita Urashima)
Sometimes I want to decide whether or not to add a particular entry to a hash depending on a condition. If the entire hash does not use nil, I can use Hash#compact. ```ruby { foo: 1, bar: bar? ? 2 : nil }.compact ``` But i...ursm (Keita Urashima)