@ mhectorgato - this is nice, just one point that should be noted, while hash table operations are in the order of O(1) the case insensitive operations are in the order of O(n). Which might not be a concern for some operations, but in cases where the hash table is used for fast lookup this would/could be a seeious concern.
Understood. It also can create a bunch of immutable strings that need to be GCed.
My purpose for this was very limited use. In my wifi helper it is used occasionally to extract ssid/pass combinations. So in my case it would used infrequently, but frequent use would be inefficient.
Again in my application, I couldn’t guarantee that the end user would enter in the key value so that it matched in case the desired value – that would be prefered. If they entered “network”, but I needed to match “Network”, then it would fail.
One potential optimization, which came to me as I am typing this, would be to do char comparisons instead of strings in the loop. I might be able to use the ASCII values & if they don’t match, add/subtract the offset between caps and lowercase.