By the way, in case it's not obvious, having Map.put() return the old value is usually good for performance. Without it, coders must sometimes do a query of the map followed by a put, which means that the same key is looked up twice.
To contrast, returning a value that is at hand but is not actually used should normally be free. It's currently not. All this is to say, we might or might not want to update the API. It's more of a win-win if the API returns the value, but the compiler can still optimize that return to nothing in cases where the value isn't actually used. Also, I'd like to emphasize Ray's comment that it's shouldn't be out of the question for the compiler to understand the lightweight collections. If tons of GWT code uses the new hash map, then a "special purpose" optimization for that specific class could still have a lot of benefit. That said, does it matter for java.util.HashMap::put? I would think that having to implement a hash table already consumes so much code that the method isn't inlineable anyway, even without the extra returned value. In that case, having an extra "return foo" at the end of the method is cheap, just like the case on the JVM. Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
