Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C# Pattern Matching

docs.microsoft.com

Post reply on HN
Print view View original

111–120 of 214 posts

Re: C# Pattern Matching

#111

Post by Merad »

alkonaut wrote: post #64
jolux wrote: post #46

Earlier quoted context omitted.

C# 8 also has nullable reference types, i.e. comprehensive nullability analysis, which is comparable though not identical to an option type. I really wish for exhaustive pattern matching and ADTs in C#, though.

It always feels a bit half baked when the class library isn’t designed with it though. It would be as if generics were added but not System.Collections.Generic. So while I long thought it would be the perfect addition to C#, I’m not so enthusiastic any more. It would be great (F# is!) but not as good as it would be in a language and platform where it was there all along. In F# this is already an issue when you want t…

Nullable reference types also feel pretty half baked with EF at the moment. If you have a non-nullable column that you want to represent with a non-nullable property in your EF model, pretty much the only option (the last time I looked) was to configure EF to use a nullable private field and access it through a non-nullable public property. It's a lot of extra work.

Re: C# Pattern Matching

#113

Post by [deleted] »

Merad wrote: post #111
alkonaut wrote: post #64

Earlier quoted context omitted.

It always feels a bit half baked when the class library isn’t designed with it though. It would be as if generics were added but not System.Collections.Generic. So while I long thought it would be the perfect addition to C#, I’m not so enthusiastic any more. It would be great (F# is!) but not as good as it would be in a language and platform where it was there all along. In F# this is already an issue when you want t…

Nullable reference types also feel pretty half baked with EF at the moment. If you have a non-nullable column that you want to represent with a non-nullable property in your EF model, pretty much the only option (the last time I looked) was to configure EF to use a nullable private field and access it through a non-nullable public property. It's a lot of extra work.

[deleted]

Re: C# Pattern Matching

#114

Post by invrmkaccounts »

alkonaut wrote: post #64
jolux wrote: post #46

Earlier quoted context omitted.

C# 8 also has nullable reference types, i.e. comprehensive nullability analysis, which is comparable though not identical to an option type. I really wish for exhaustive pattern matching and ADTs in C#, though.

It always feels a bit half baked when the class library isn’t designed with it though. It would be as if generics were added but not System.Collections.Generic. So while I long thought it would be the perfect addition to C#, I’m not so enthusiastic any more. It would be great (F# is!) but not as good as it would be in a language and platform where it was there all along. In F# this is already an issue when you want t…

This will get fixed in due time:

>What will Microsoft do?

>We will also aim to be done with null-annotating our core libraries when .NET 5 (November 2020) comes around – and we are currently on track to do so. [1] [2]

[1] https://devblogs.microsoft.com/dotnet/embracing-nullable-ref...

[2] https://github.com/dotnet/runtime/issues/2339

Re: C# Pattern Matching

#115

Post by bernawil »

emodendroket wrote: post #107
bernawil wrote: post #76

Earlier quoted context omitted.

How is that particularly functional? In Haskell the same example would be approached at type-level using type classes, something extremely similar to using Interfaces. I guess in a dynamic functional language you'd probably avoid doing this type of contact-oriented stuff, but you'd rather pass a callback at the last point rather than check type of what you got passed.

I worked in Scala for a while and it was pretty common to use these kind of pattern-match statements for a kind of dispatch mechanism. Not even necessarily with types, it might be something like "do one thing when field a is null and field b is not, another thing when it's the other way around, another thing when they're both null, and still another when neither is." The nice thing about it is the compiler can assert…

> do one thing when field a is null and field b is not

And that would have been a good example! contrary to the one in the docs.

Pattern matching for checking fields of things of the same type is a good use. Pattern matching when checking your parameters type? bad.

> The nice thing about it is the compiler can assert that your match is exhaustive

If you pass a new Shape object for which you forgot to implement a new case in the pattern matcher, you just get the default case, which is wrong, but the compiler can't know that. Now have the function argument ask for something that implements IArea interface and if you don't implement getArea() in your new Shape class, the compiler will know.

Re: C# Pattern Matching

#116

Post by hermitdev »

mumblemumble wrote: post #26
mindfulplay wrote: post #2

Such a beautiful, elegant language. Simple to grasp and lets the compiler handle all that legitimate complexity. Wish more language designers would respect code authors like these designers do.

I suspect that it's not an issue of respect so much as an issue of governance. C# remains a commercial language, wholly owned by a single corporate entity. That, I think, allows its maintainers some luxuries that community languages don't enjoy. Chief among them is a whole team of full-time language designers and implementers who can sustain a sort of deep concentration 40-ish hours a week for years on end. I'm prett…

C# is an ECMA spec. Albeit a spec that is largely driven by MS and often lags behind implementations of .Net framework/core.

Re: C# Pattern Matching

#117

Post by tucaz »

jcpst wrote: post #84
S_A_P wrote: post #3

Resharper has proven to be a great way for me to start learning and integrating new language features. I code in my original style and resharper suggests changes based on new features like pattern matching. At first I didnt see the benefit, but this is a hugely powerful feature once you start to wrap your mind around it.

I have clocked in way more hours in Rider than VS. I can flawlessly run and debug our decades old monolith with 40-50 projects and millions LOC, containing C#, VB, Web Forms, WPF, files with 80k lines... And all of our .NET Core services on MacOS, with all my unix-y tooling. There is “VS for Mac”, but it’s not really VS. It’s Xamarin Studio rebranded. Rider works excellent on my Linux box at home as well, where the a…

I switched to Rider a few months ago but I still feel like I struggle with some things.

For some reason I can’t change the position of the debugger when running and aspnetcore app and make it go back so I always have to re-run whatever request I happen to be debugging. Does that happen to you?

It also seems like ReSharper had more tips and tricks going on when compared to Rider, but I can’t imagine that would be true.

Re: C# Pattern Matching

#118

Post by tucaz »

emodendroket wrote: post #99
flamtap wrote: post #86

Earlier quoted context omitted.

As a long-time ReSharper user, I’ve been meaning to give rider a close look for some time now. Unfortunately the last project I was on was heavy into WPF, and that was about the only box VS didn’t tick. Any tips, tricks, or pitfalls to avoid making the switch from VS to Rider?

I used VS for years before switching to Rider and honestly... just jump in, there's not much to know. If you've used ReSharper the features should seem pretty familiar.

What do you think is better in Rider? I’m using it myself for a few months now but feel like going back to VS all the time.

Re: C# Pattern Matching

#119

Post by totalperspectiv »

DaiPlusPlus wrote: post #96
bob1029 wrote: post #52

Earlier quoted context omitted.

You should try it out sometime, regardless of coercion. There isn't much of a barrier to entry anymore. Even installing VS2019 is a pleasant experience now. I have yet to meet a developer who gave C# a legitimate try and then decided it was entirely not for them. That said, I only personally know developers who are working in the realm of B2B application development, so perhaps there are other incompatible use cases…

Data science, vision, etc - this is where Python reigns supreme and using C# is really going against the rest of the industry. Using OpenCV from .NET is painful, but from Python it feels native.

Yeah, this is basically the boat I'm in. Python dominates. You either write it in Python, or maybe get away with writing it in something else and then wrapping it in Python.

I don't mind Python, but now that I've gotten a taste of ADT's and non-nullable types, writing Python feels like a kludge.

Re: C# Pattern Matching

#120

Post by Serow225 »

eyegor wrote: post #93

Heads up for C# devs, you should switch all your code bases to use (x is null) and !(x is null) instead of ==. The is operator can't be overloaded, and always compiles to IL eq, whereas == can be overloaded in custom types. Of course it would also be nice if everything was moved to nullable reference types [0], but that's a non trivial amount of work. Note that most C#8 features can be enabled manually through the cs…

a number of the C# lang developers prefer (x is object) for the latter, FWIW.
Post reply on HN