I likewise have never wanted an updated hash with the matched keys removed. Moreover, if I did want such a thing, I think it could easily be implemented as a library match expander using and and app.
In my latest proposal, there are three modes: #:full, #:partial, and #:rest. If you don’t want the rest hash table, simply don’t specify #:rest.
this example: …. prompted me to think
Well, that example, in my view, is biased. I think everyone agrees that if you are to match a JSON object, partial matching is the way to go. But JSON object is just one use case for the hash table.
I don’t hate partial matching. In fact, what prompted me to discover the issue in https://github.com/racket/racket/pull/4532 and subsequently made this RFC, was that I was working on https://github.com/racket/scribble/pull/328 and needed a way to do partial matching.
My argument for the full matching by default for hash, again, is that when you look at all other patterns, especially those that mirror their corresponding constructors, they fully match. That’s the default expectation. So why shouldn’t hash that is specifically designed to mirror the constructor fully match too?
As I expressed before, if I am restricted to adding only one pattern, I would just add hash* (with the name of hash), which has partial matching by default.
But a lot of people prefer consistency. They want a pattern that mirrors the constructor (which I personally don’t really care about), so now we have two patterns: hash and hash*. And if mirroring the constructor is the motivation for having hash like that, I don’t see why it shouldn’t be a full matching too.
Maybe it would be useful to articulate why we’re discussing adding a pattern with special support from match, rather than a pure library extension? (That is what we’re discussing, right?) I think it’s a combination of (a) bugs in hash-table and (b) potential efficiency gains from cooperation with match’s optimizer, but maybe there are other reasons.
It’s mainly because of the bugs in the existing hash-table. I need to add something so that users can switch over and stop using the buggy pattern. hash-table is already expressible as a match expander. Same for the proposed hash and hash*. There’s no efficiency gain.
If that’s so, maybe it would help to figure out what the new primitive functionality we want from match is before pinning down a preferred surface syntax. Ideally, the right primitives would allow many possibilities to be implemented efficiently as library extensions.
In my view, we have already done that in the first phase of this RFC. But I am now trying to wrap it up and start implementing it.