[HN Gopher] Show HN: Match(it): A C++17 pattern-matching library...
___________________________________________________________________
Show HN: Match(it): A C++17 pattern-matching library with lots of
good stuffs
A lightweight single-header pattern-matching library for C++17 with
macro-free APIs. Try it at https://godbolt.org/z/8YMr8Kz8j
Author : amazing42
Score : 70 points
Date : 2022-08-17 13:36 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fouronnes3 wrote:
| Very nice looking. Can you pattern match std::variant?
| amazing42 wrote:
| Yeah. That is supported.
| synergy20 wrote:
| Thought it's about regex matching for switch-case, turns out it's
| very different, interesting though, is this an idea borrowed from
| Rust? Not sure if I'm going to use it or not.
| klyrs wrote:
| Pattern matching has quite a long history[1]; it's been around
| in some form since 1957. It's been enjoying a bit of a
| renaissance lately; I suspect that's a result of Haskell's
| popularity but I don't really know.
|
| [1] https://en.wikipedia.org/wiki/Pattern_matching
| synergy20 wrote:
| Not a CS major, thanks for the link!
| bhedgeoser wrote:
| Rust version:
|
| const fn factorial(n: u128) -> u128 { match n { 0 => 1, _ => n *
| factorial(n-1) } }
|
| fn main() { dbg!(factorial(20)); }
| dymk wrote:
| What a neat concept. It never ceases to amaze me what people can
| arm-bar C++ into doing through typesystem, metaprogramming, and
| operator overloading shenanigans.
|
| I hope I never see this in a production codebase, though!
|
| On a kind of related note, I want to see an alternate history
| where C++ had support for Rust-ish proc macros, or Racket-ish
| macros. What would that language even look like? There'd probably
| be no need to hack existing C++ language semantics to add new
| features, you'd "just" generate the code that the meta-language
| lowers to.
| Longhanks wrote:
| > I hope I never see this in a production codebase, though!
|
| Why? Looks completely readable, easy to understand to me.
|
| Do you also hope to never see the STL in production? Because
| internally, that thing is high level unreadable C++.
| dymk wrote:
| I say that because I would hate to be the person that has to
| ramp up a junior engineer on a project that uses a library
| like this.
|
| I've written my fair share of code like this, and while you
| and I might grok it (and probably have a fun time figuring
| out how it works in the process), most people will hit a
| brick wall the moment they have to debug the 1000 line error
| that Clang or GCC will give you when there's a type error.
|
| This is the kind of thing that belongs in language-feature
| land (so you get tooling support, reasonable compiler errors,
| etc), not library-land.
| kubb wrote:
| You think a junior can't understand how this library works
| and use it safely?
| dymk wrote:
| In my experience, which was introducing engineers at
| Facebook to "fancy" C++ stuff, no.
| pclmulqdq wrote:
| In my experience at G introducing modern C++, the most
| senior engineers had the biggest problems with it. Junior
| engineers hated the cryptic errors a lot more, though.
| spkm wrote:
| TBF, _everyone_ hates these cryptic errors :)
| Kranar wrote:
| It's interesting you mention junior engineers. My
| experience is the complete opposite, it's people who have
| been programming for many years who hate learning stuff
| like this and want to stick to their comfortable way of
| programming, whereas those who have programmed for fewer
| years enjoy learning about this and actually have fun doing
| so.
|
| Perhaps unsurprisingly the author of this library looks to
| have only a few years of experience themselves.
| Longhanks wrote:
| > This is the kind of thing that belongs in language-
| feature land (so you get tooling support, reasonable
| compiler errors, etc), not library-land.
|
| Again bringing up my STL example: This is just not how C++
| runs. I've seen my fair share of
| std::__v1::basic_string<char, char_traits<char>,
| DefaultAllocator<>> errors. Some would argue a string type
| should be language-level, and they might be right, but the
| committee disagrees.
| dymk wrote:
| Right, well, I think we can agree the committee makes
| some _weird_ calls sometimes with respect to language
| design. We only got concepts and coroutines (relatively)
| recently, and they 're still kind of warty. `std::range`
| is beautiful and I'd still only use it sparingly. The C++
| language, in my experience, is a language best served as
| a safe subset with "magic" and advanced features eschewed
| as much as possible.
|
| The C++ STL has a lot of templated code in it
| (obviously), but at least the amount of weird tricks,
| such as template recursion, is fairly small (ignoring
| newer additions like `std::range`). And even then,
| compiler errors can make an experienced engineer's eyes
| water. At least you can paste most errors into Google and
| find a relevant StackOverflow post about how to fix it.
|
| Involving a library like this, though - best of luck, the
| engineer is on their own.
| spkm wrote:
| It's my impression that people tend to underestimate
| "junior engineers" in the C++ world. I'm always impressed
| at conferences that there are so many young people holding
| presentations about really advanced topics.
|
| IMHO this "no junior will ever understand that" attitude
| comes mostly from older folks who learned C++ as C with
| classes and to whom even the STL is a work of the devil.
| formerly_proven wrote:
| > Do you also hope to never see the STL in production?
| Because internally, that thing is high level unreadable C++.
|
| SGI/HP STL isn't nearly as bad as modern implementations,
| though they all __share _Weird ____identifier names, mostly
| because of C/C++ identifier rules (_[A-Z] and anything with
| __ are reserved for the implementation, everything else might
| just be #define'd to rick-roll by whatever program is
| including you).
| robbintt wrote:
| The Define problem seems like low hanging fruit for a
| linter/formatter.
| gpderetta wrote:
| That alternative history is currently being implemented by the
| Circle compiler.
| olvy0 wrote:
| Interesting - in the godbolt.org link, looks like both GCC and
| Clang optimize the code to run at compile time, so the resulting
| function is just "mov eax, 24".
|
| But MSVC latest instead generates the full runtime code and
| function call.
| phoe-krk wrote:
| Strangely, clang 13+ seems to have regressed - it emits runtime
| code as well, whereas clang 12 has just "mov eax, 24".
|
| Should this be reported anywhere?
| jokoon wrote:
| I hope this will become part of C++ one day.
|
| Although if the C++ committee manages to add this without
| deprecating other things, I would be impressed.
| corysama wrote:
| There has been a proposal to add pattern matching to C++ for
| nearly a decade now
| https://www.stroustrup.com/OpenPatternMatching.pdf Shame it
| never got in. With language support for matching, sum types and
| product types it would be a completely different language.
| pclmulqdq wrote:
| The regex library in the STL was quite a lesson for the C++
| maintainers. They will probably not allow anything similar
| any time soon.
| tialaramex wrote:
| Although the phrase "pattern matching" is involved these
| are completely different features.
|
| Also, unlike for regular expressions what you actually want
| here is typically a language feature, even if a bunch of
| the lifting is done in your standard library. In particular
| you probably want a keyword (or in several C++ pattern
| matching proposals, more than one) and new behaviour not
| just a few functions and constants.
|
| You _could_ think of this as a bit like "switch" but on
| the other hand if your insight into switch is that it's
| basically a computed go-to wearing fancy dress then no, not
| that, the thing ordinary people use switch for.
| UncleOxidant wrote:
| Wouldn't it be very similar to Rust? (or OCaml - but without
| the automatic memory management)
| hkalbasi wrote:
| Not super useful without ADTs, but nice! I hope someday ADT and
| pattern matching find their way to the c++ language.
| [deleted]
| fooker wrote:
| Wow, I didn't know you could #include a remote file in compiler
| explorer.
___________________________________________________________________
(page generated 2022-08-17 23:01 UTC)