It is not just 'syntax'. Also I think a substantial portion of developers or the programming industry at large do not think these sort of tools are `useless`.
I am not saying the functionality is useless, but it already exists in other languages. Why force C# to look and behave like F# instead of just using F#?
I think most of the people creating and using these libraries would use F# if they could sadly. (However I am one of the lucky ones doing clojure in my day job.) Also a lot of existing software that needs to be maintained in C# would benefit from this library or others like it, just like they would benefit from having tools like linq, immutable collections, tpl available.
Feel free to pilfer some ideas from my own take on a similar lib for C#. https://github.com/danstone/lambit - includes some basic pattern matching support for example.
This sort of library is kind of necessary I feel for things like poor tuple support at least.
I'm not entirely sure about the casing conventions. I mostly code in clojure/haskell/f# but 'when in rome'. Its likely the sort of thing that will turn off a lot of stubborn developers.
Yeah I've implemented a similar pattern matching library before (not public though). I always felt the syntax to be a bit 'bulky' because there were always two lambdas, one for the predicate and one for the handler.
I like your take on list matching though, I think that's excellent and much more usable. Not 100% sure how it could be adapted in a general way to the C# Tuple though; because Tuple<A,B> is a different type to Tuple<A,B,C>. So you could only ever match on one type (if you don't take the bulky predicate route that is).
List matching tends to be fairly useful even its very limited form in my lib. Its basically arity match + de-structure. It doesn't nest like full fat pattern matching.
I don't see how tuple matching is as useful (over your 'With' fn or my 'Apply') unless it can nest, especially with matches on union types.
e.g (Maybe a, b) | (Nothing, b)
Basically I feel like such a thing is going to be very hard in C# to achieve with any sort of usable api. I personally took the route of the api being more important than whether any sort of decent abstraction is actually there behind the scenes - I didn't mind writing 100's lines of boilerplate to get the result and behaviour I wanted.
Its great to see more functional support for C# from the community and I look forward to using your lib in the future!
