Named tuple string key access #3143
Conversation
jhass
force-pushed
the
named_tuple_string_keys
branch
from
0e1a2f6 to
58a16c3
Compare
|
I'm almost 👍 on this, I need to check with @waj. I'd also need to add a rule to the compiler to simplify named tuple indexing with string literals, like it's done now with symbol literals (a very easy change) |
| t["foo"]? | ||
| )) { nil_type } | ||
| end | ||
|
|
There was a problem hiding this comment.
Not sure if that's the right place for these specs, but couldn't find anything else.
jhass
force-pushed
the
named_tuple_string_keys
branch
3 times, most recently
from
6bca933 to
af48e1b
Compare
jhass
force-pushed
the
named_tuple_string_keys
branch
from
af48e1b to
88fdd4f
Compare
| # ``` | ||
| def gsub(tuple : NamedTuple) | ||
| gsub do |char| | ||
| tuple[char.to_s]? || char |
There was a problem hiding this comment.
Should we haveTuple#fetch to allow proper non-fallbacking when the actual value is falsy?
Not particularly needed in this case, but It's been a week with hash[key] || default bugs on my side :-)
Maybe adding Indexable#fetch?
Hash#fetch currently uses #find_entry, so I don't expect to promote that method to the module.
There was a problem hiding this comment.
Should I change something here or do you consider it a separate change? (I think I do personally). Note that the same pattern is currently in use for the existing Hash(Char, _) overload.
There was a problem hiding this comment.
Yeah, let's do it in a separate commit and get this merged. Apologies for the delay @jhass
|
@jhass Excellent, thank you! |
Implements #2966