Hello and thank you for your comments. > The keyword match would definitely conflict with variables names. This doesn't seem like a huge issue to me but certainly I'd be happy with expanding switch instead if it allows us to do the same sort of thing.
> To me this looks like a Pythonism where several lines worth of logic get shoved into one line. It doesn't fit the standard simplicity of the language. Maybe in my second example that happens, but that was me trying to make some more advanced suggestions, and they're not really necessary to integrate my core idea. > I think the potential of a switch that can handle multiple values would be interesting. I think so too, but this wouldn't even completely implement my first example, which includes also usage of a _ wildcard. And it would be a shame to completely rule out destructuring and guards (seen in my third example) as a consequence. Nadim Sent from my computer On Wed, Jun 5, 2019 at 7:30 AM Nicholas Eden <nicholas.e...@gmail.com> wrote: > I am not a fan of the match syntax you're proposing. It seems like a > modified switch which does an assignment and doesn't have 'case' in the > statements. The keyword match would definitely conflict with variables > names. To me this looks like a Pythonism where several lines worth of logic > get shoved into one line. It doesn't fit the standard simplicity of the > language. > > I think the potential of a switch that can handle multiple values would be > interesting. It follows and extends a syntax that we already know, as well > as works in tandem with multiple returns. It would be easy to explain and > document because it is the natural next step. I don't think there would > even be a breaking change potential. > > > > On Tuesday, June 4, 2019 at 9:47:48 PM UTC-7, Nadim Kobeissi wrote: >> >> Hello everyone, >> >> This is my first post to this list so please excuse me if I'm not >> following all of the proper traditions for this community (posting this in >> the wrong place, etc.) >> >> I like Golang a lot and I think that it's a gift to people who love >> computer programming. I have written three softwares in Golang and I'm >> really having a great time with this language. >> >> I was wondering if people would be interested in discussing the inclusion >> of pattern matching syntax in Golang. By "pattern matching" I do not mean >> regular expressions, but rather a feature that is seen in other >> languages such as OCaml >> <https://caml.inria.fr/pub/docs/oreilly-book/html/book-ora016.html>. >> >> Rust also has this feature, which it simply calls "Patterns" >> <https://doc.rust-lang.org/1.5.0/book/patterns.html>. In particular >> Rust's implementation of this feature seems quite excellent actually. >> >> I think adding patterns/pattern matching to Golang would allow it to be >> used much more seriously in situations like building a parser, transpiler, >> compiler etc.. I'm sure there are other uses as well. >> >> Here is an example of what I have in mind: >> >> // Just some code to later demonstrate my proposition >> func getDayAndDate() (string, int) { >> date := getDate() >> if todayIsTuesday() == true { >> return "tuesday", date >> } >> return "not tuesday!", date >> } >> >> var result string >> >> // What I am proposing starts here (the below is currently not valid >> Golang code) >> result = match getDayAndDate() { >> "tuesday", _: "wow looks like it's tuesday", >> _, 5: "i don't know if it's tuesday but it's the fifth! nice!", >> "not tuesday!", _: "not a tuesday my dude", >> } >> >> Wouldn't that be cool? I don't think that existing Golang syntax allows >> us to accomplish stuff like this so elegantly. We'd have to do something >> really convoluted. The following doesn't work since switch can't handle >> functions with multiple return values: >> >> switch getDayAndDate() { >> case "tuesday", 5: >> println("cool!") >> } >> >> switch also can't handle the _ wildcard as a case value. So really there >> is no serious alternative to achieve pattern matching in Golang right now, >> as far as I can tell. >> >> I tried searching the Internet, including this mailing list, for previous >> discussions of this topic, and the only thing I could find was a post >> dating to eight years ago with little follow-up. >> >> I genuinely believe this is a great feature for Golang to pursue and I >> wonder if we can get the developers of this fantastic programming language >> and toolkit to take this feature more seriously. I'd be happy to help >> implement it myself if I can! >> >> Thank you, >> >> Nadim >> Sent from my computer >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/JAcxQqVLqUI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/fb2dee22-181d-45f7-917d-6da114fd20dd%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/fb2dee22-181d-45f7-917d-6da114fd20dd%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAK-38xVE-soxEogGiU69oOzjg1PPfsfVp0x42yeNYpO5PNbnaw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
