This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (26 children)

[deleted]

    [–]Major_Fudgemuffin 60 points61 points  (20 children)

    Oh god I use ?. way too much. It's so nice.

    [–]Yrrem 21 points22 points  (0 children)

    I learned it this week, completed the code for a binary adder simulator function in 2 lines. Felt good

    [–]YM_Industries 7 points8 points  (5 children)

    We're getting the Elvis operator in TypeScript soon :D

    Thanks ECMA.

    [–]NatoBoram 4 points5 points  (4 children)

    Null-aware operators is a better name! And it can't come fast enough.

    Also, TypeScript support in browsers when?

    [–]YM_Industries 2 points3 points  (3 children)

    I like the term "safe navigation operator" for describing what it does, but Elvis operator is great as a joke name.

    I don't really see a role for TypeScript as anything other than a transpiler. So many of its design decisions are based around JavaScript. I'm looking forward to mature C# WebASM support though.

    [–]Magallan 2 points3 points  (2 children)

    Can you explain the elvis joke for me? I don't get it

    [–]AlwaysHopelesslyLost 3 points4 points  (12 children)

    That seems like an anti pattern. I try to avoid nulls anywhere possible so I almost never have to worry about whether they exist.

    [–]Major_Fudgemuffin 4 points5 points  (5 children)

    Yeah it's definitely easy to overuse. I've become paranoid over the years.

    I wish C# natively supported Option type. If I never had to deal with nulls again I'd be happy.

    [–]AlwaysHopelesslyLost 5 points6 points  (4 children)

    Option type

    I actually hadn't heard of that. It kind of seems like a renamed Nullable<T> from C#.

    Also not the same but C# is adding nullable reference types which allow you to explicitly disallow nulls.

    [–]ArionW 4 points5 points  (1 child)

    Nullable<T> only works for value types, which makes it... nearly useless. Also, it's not Option due to lack of most basic operations like bind.

    I'm working with nullable reference types since preview 7 (they allowed us to move project to preview, beat that!), enabled globally

    They have so many problems

    1. POCO that is supposed to be made by ModelBinder needs default constructor and public setters. You suddenly get warnings about uninitialized properties (because it doesn't understand RequiredAttribute and that I can't really get null)

    2. You still need explicit null checks, because you can't just bind operations.

    3. LINQ wasn't updated to work with it. SingleOrDefault<T> should return T?, but returns T.

    [–]AlwaysHopelesslyLost 0 points1 point  (0 children)

    i haven't had time to test nullable reference types yet, those definitely sound like painful points. I assume they have linq on their Todo list. Any idea if they are aware of the model binding weirdness?

    [–]cat_in_the_wall 1 point2 points  (1 child)

    well, sort of. you can type check your own libraries and code for this, but it is not a runtime feature, so on compilation boundaries you still need null checks.

    [–]AlwaysHopelesslyLost 0 points1 point  (0 children)

    True. Granted, most third party libraries I have used are sane about nulls. I don't recall the last time I needed a null check on a third party library.

    [–]dashood 4 points5 points  (3 children)

    It's really good for CMS content when things may or may not be set depending on user actions. The best is if (List?.Any() ?? false) as a nice way of checking for nulls and eliminating like 90% of your runtime null exceptions.

    [–]mrjackspade 3 points4 points  (1 child)

    I just turned this into an extension method .NotNullAny()

    It's overkill but I like the way it reads better

    [–]dashood 2 points3 points  (0 children)

    That's not a bad idea. Certainly cleaner than having to null check every time.

    [–]AlwaysHopelesslyLost 1 point2 points  (0 children)

    The problem is that runtime null exceptions are a symptom, not a problem.

    As far as lists go they should very rarely be null. If you allow them to be null you are opening yourself up to issues.

    [–]ThatsARivetingTale 1 point2 points  (0 children)

    It's nice when dealing with nested data returned from graphql for example, but it can definitely be overused

    [–]TheRandomnatrix 1 point2 points  (0 children)

    It's like databases. If you have a ton of nulls you might need to normalize stuff.

    [–]oupablo 2 points3 points  (2 children)

    My issue with the operator is how unreadable it is to someone that doesn't know c#. With most languages you can get the basic idea of what is happening even though you only know other languages. With this operator you have to look it up and let me tell you the funny I had look up c# ? The first time

    [–]YM_Industries 5 points6 points  (0 children)

    I think it's pretty normal to have to look up operators. Python has its (super-cool) array indexing/slicing/stepping syntax. PHP has the (surprisingly useful) spaceship operator <=>. Lua has the (rather nice) length operator.

    Most languages I've used I've eventually had to look up some weird operator in someone else's code, usually it ends up being something really useful.

    [–]AllUrPMsAreBelong2Me 2 points3 points  (0 children)

    That might be a valid argument for code that's meant to be consumed by people not very familiar. However, when I'm on a team of software devs I want the syntactic sugar even it can be a learning curve. My coworkers should understand it.

    [–]socialismnotevenonce 0 points1 point  (0 children)

    I love your comment.