refactor: unpack & try_unpack

[max-sixty]

As I mentioned on Discord. Inspired by this discussion

• This is me trying to become more acquainted with the code
• We don't have to merge it (genuinely)
• Though I do find this code simpler to understand
• It's less impressive rust, maybe less abstract, less use of the type system
• It's the same verbosity, as measured by lines of code
• It does more allocating, more .clone()
• But it's actually slightly faster on cargo bench, about 3% on my machine
  • It doesn't run each try_into_* before doing the next one if that fails
  • Maybe it allows for fewer eventual optimizations in the future though?
• It would need a quick pass to add the regex from today

GPT-4 helped me a lot!

---

• I added a couple of notes on further changes. We're probably doing too much if args.len() == X in lots of places, and could have these as structs & enums in rust, though I'm not sure how deep in the compiler we want them (maybe there's a difference between functions & operators?)

[aljazerzen]

Ideally, this would use std::STD_X so we have it "linked" with RQ.

[max-sixty]

Yes, I left some notes here, I agree the current state isn't ideal. I'm not sure how much we want to have these deep in the compiler with something like an Enum...

[aljazerzen]

This is way better, as in way more readable.

I went too deep with the no-clone frenzy :D It's actually slower probably because it was searching for impl of functions in linear search. This PR is now using sub-logarithmic lookups (because it's using match).

[max-sixty]

This is way better, as in way more readable.

I went too deep with the no-clone frenzy :D It's actually slower probably because it was searching for impl of functions in linear search. This PR is now using sub-logarithmic lookups (because it's using match).

OK great! Thanks for being open. I was holding that it was "worse but easier rust" — maybe it's actually / actually much worse. I do think this sort of change can make it easier for others to contribute...

I'll update to yesterday's regex addition, resolve hte comments, and leave a couple of notes re strings vs FunctionDecls (i.e. #2532 (comment))

[max-sixty]

...and using slice patterns reduces some of the if args.len... verbosity: e6fc1f2

[max-sixty]

I'll merge given your ✅ , but happy to do follow-up with any other changes