Live data from Hacker News

What's New in C# 14: Null-Conditional Assignments

blog.ivankahl.com

51–60 of 174 posts

Re: What's New in C# 14: Null-Conditional Assignments

#51

Is .NET entering its twilight years as a tech people build new things with? I just can't imagine Gen Z wanting to start a project in C#. I realise there are still .NET shops, and I still talk to people who do it daily, but ours is a field driven by fashion whether we care to admit or not - and C# just does not feel as fashionable as it once did (I'm a former C# dev, up until 2020)

It is definitely out of fashion, most directly in comparison to Go I suppose. It seems like they tried with .NET Core, but were not able to provide an appealing and coherent enough on-ramp. The ongoing death of native windows applications not helping either certainly.

Re: What's New in C# 14: Null-Conditional Assignments

#52

Earlier quoted context omitted.

From the article: > If config?.Settings is null, the assignment is skipped. If the right hand expression has side effects, are they run? I guess they do, and that would make the code more predictable.

From the article as well: Side-Effect Prevention When a null-conditional statement assignment is evaluated, the right-hand side of the expression is not executed unless the left-hand side is defined.

Thanks. I missed it.

I really dislike that, because it hides the control flow too much. Perhaps I'm biased by Racket, where it's easy to define something weird using macros, but you should not do unexpected weird things.

For example you can define vector-set/drop that writes a value to a position of a vector, but ignores the operation when the position is outside the vector. For example

  (vector-set/drop v -2 (print "banana"))
With a macro is possible to skip (print "banana") because -2 is clearly out of range, but if you do that everyone will hate you.

Re: What's New in C# 14: Null-Conditional Assignments

#53

Is .NET entering its twilight years as a tech people build new things with? I just can't imagine Gen Z wanting to start a project in C#. I realise there are still .NET shops, and I still talk to people who do it daily, but ours is a field driven by fashion whether we care to admit or not - and C# just does not feel as fashionable as it once did (I'm a former C# dev, up until 2020)

I personally can't think of an all-rounder language that is better than C#. It's fast, has great tooling, powerful, extremely productive for working with large code bases and runs 'anywhere'.

JS has lost against TS which is basically C# for web (both designed by the same person) and Python is not really something you should build large applications with (execution speed + maintenance issues).

What do you believe is the current language du jour?

Re: What's New in C# 14: Null-Conditional Assignments

#54

It's starting to feel like C# is going down the path of C++. Tons of features that introduce subtleties and everybody has their own set of pet features they know how to use. But the code gets really hard to understand when you encounter code that uses a subset you aren't familiar with. I remember staring at C++ codebases for days trying to figure out what is going on there. There was nothing wrong with the code. I ju…

The difference is the language syntax choices are good. There's no "what does this const refer to" type confusion.

Re: What's New in C# 14: Null-Conditional Assignments

#55
post #2

Isn't this more confusing? Because it skip the code if the value is null and I don't think it is normal to follow the flow assuming nothing has happened.

From the article: > If config?.Settings is null, the assignment is skipped. If the right hand expression has side effects, are they run? I guess they do, and that would make the code more predictable.

[deleted]

Re: What's New in C# 14: Null-Conditional Assignments

#56
post #19

Earlier quoted context omitted.

What?.could?.possibly?.go?.wrong?.

if (This) { if (is) { if (much) { if (better) { println("I get paid by the brace") } } } }

    if (Actually 
        && Actually.you
        && Actually.you.would
        && Actually.you.would.write
        && Actually.you.would.write.it
        && Actually.you.would.write.it.like) {
            return this;
    }

Re: What's New in C# 14: Null-Conditional Assignments

#58
post #19

Earlier quoted context omitted.

if (This) { if (is) { if (much) { if (better) { println("I get paid by the brace") } } } }

False dichotomy. The problem is that the syntax implements a solution that is likely wrong in many situations and pairs with a bad program design. Maybe when we have this: what?.could?.possibly.go?.wrong = important_value() Maybe we want code like this: if (!what) what = new typeof(what); // default-construct representative instance if (!what.could) what.could = new typeof(what.could); if (!what.could.possibly.go) wh…

> Maybe we want code like this

It should be clear enough that this operator isn't going to run 'new' on your behalf. For layers you want to leave missing, use "?.". For layers you want to construct, use "??=".

> Why would you ever write an assignment, but not expect that it "sticks"? Assignments are pretty important.

If you start with the assignment, then it's important and you want it to go somewhere.

If you start with the variable, then if that variable doesn't have a home you don't need to assign it anything.

So whether you want to skip it depends on the situation.

> What if someone doesn't notice the question marks and proceeds to read the rest of the code thinking that the assignment always takes effect? Is that still readable?

Do you have the same objection with the existing null-conditional operators? Looking at the operators is important and I don't think this makes the "I didn't notice that operator" problem worse in a significant way.

Re: What's New in C# 14: Null-Conditional Assignments

#59

Earlier quoted context omitted.

What?.could?.possibly?.go?.wrong?.

Nothing to worry about: What?.could?.possibly?.go?.wrong? Not so convinced: What?.could?.possibly?.go?.wrong = important_value() Maybe the design is wrong if the code is asked to store values into an incomplete skeleton, and it's just okay to discard them in that case.

[dead]
Post reply on HN