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

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

blog.ivankahl.com

Post reply on HN
Print view View original

161–170 of 174 posts

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

#161

Post by throw-the-towel »

opticfluorine wrote: post #140
SeasonalEnnui wrote: post #132

The thing I enjoy most about C# is the depth/levels of progressive enhancement you can do. Let's say in the first instance, you write a proof of concept algorithm using basic concepts like List , foreach, stream writing. Accessible to a beginner, safe code, but it'll churn memory (which is GC'd) and run using scalar CPU instructions. Depending on your requirements you can then progressively enhance the memory churn,…

I have occasionally, just for fun, written benchmarks for some algorithm in C++ and an equivalent C# implementation, them tried to bring the managed performance in line with native using the methods you mention and others. I'm always surprised by how often I can match the performance of the unmanaged code (even when I'm trying to optimize my C++ to the limit) while still ending up with readable and maintainable C#.

Could you please share some benchmark code? It would be incredibly useful as a learning aid!

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

#162

Post by kazinator »

Dylan16807 wrote: post #156
kazinator wrote: post #152

Earlier quoted context omitted.

> If you want to make sure the value doesn't disappear, you shouldn't be using conditional assignment in the first place. If it worked using "materialize-on-write" semantics, why wouldn't you, as an alternative to the verbose code which checks every path component that might not exist, and instantiates it before doing the assignment? Obviously, you can't use it if you don't have materialize-on-write semantics in the…

If it materialized instead, yeah that sentence wouldn't apply the same way. But materializing with a default constructor opens up many cans of worms. I would say it has significantly more downsides than short circuiting. Also it should use a different operator.

Small additional point: if it used a different operator, what if that operator was used in an expression that is not the target of an assignment? Does that operator just become equivalent to ?, or does it do the materializing anyway even though it is not required in support of an assignment?

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

#163

Post by Dylan16807 »

kazinator wrote: post #162
Dylan16807 wrote: post #156

Earlier quoted context omitted.

If it materialized instead, yeah that sentence wouldn't apply the same way. But materializing with a default constructor opens up many cans of worms. I would say it has significantly more downsides than short circuiting. Also it should use a different operator.

Small additional point: if it used a different operator, what if that operator was used in an expression that is not the target of an assignment? Does that operator just become equivalent to ?, or does it do the materializing anyway even though it is not required in support of an assignment?

It would probably materialize no matter what.

But syntax error would be fine.

Definitely not acting the same as a question mark.

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

#164

Post by esafak »

jayd16 wrote: post #56
esafak wrote: post #19

Earlier quoted context omitted.

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; }

Routinely dealing with that's enough to put you off programming altogether.

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

#165

Post by hirvi74 »

notTooFarGone wrote: post #141
moogly wrote: post #34

Earlier quoted context omitted.

I'm also not sure I have a lot of code where this would be useful, but adding it to the language I don't feel makes it worse in any way; in fact, it makes it more consistent since you can do conditional null reads and conditional null method invocations (w/ `?.Invoke()`), so why not writes too.

Adding something is always gonna make things worse by default and has to be proven to be useful. Otherwise you have bloat and "yet another way of doing the one thing". I'm a fan of this notation because it's consistent but language design should not just add features because it doesn't hurt.

I enjoy language features like this too. In fact, I love how languages like C# have handled nullability over the more recent years. No telling how many bugs I have prevented.

The only gripe I have though, is that I have to be remember which version does and does not support such syntax changes. It's not a major issue by any means, but when dealing with legacy applications, I tend to often forget what is and is not syntactically allowed.

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

#166

Post by peterashford »

pjmlp wrote: post #111
peterashford wrote: post #47

I'm a Java fan so I'm contractually required to dis c#, but actually I kinda like this. It reduces boilerplate. Yes, it could be abused but this is what code review is for.

Why the requirement, because of J++ and how Ext-VOS alongside Cool became .NET? Most companies don't care about this kind of stuff. I work across Java, C#, JS/TS, C++, SQL, and whatever else might be needed, even stuff like Go and C, that I routinely criticise, because there is my opinion, and then there is the job market, and I rather pay my bills.

Yeah, I work with lots of languages too. Including c#, as it happens.

It was a joke.

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

#167

Post by paulmooreparks »

jobigoud wrote: post #135
paulmooreparks wrote: post #117

Sorry, I would flag this in a code review. It's too easy to skip past this visually. Explicit if statements make it a lot more obvious what's going on. This is too much syntactic sugar.

You must not do a lot of C# code reviews? This syntax is used in every codebase. In fact if you don't use it Visual Studio will underline it as "code can be simplified" suggestion. You've never seen something like this? MyEvent?.Invoke(sender, arg);

I work almost exclusively in C#, and I do a lot of reviews. I'm familiar with the syntax, and I use it. It's the assignment version that I'm talking about here.

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

#168

Post by mrkeen »

kazinator wrote: post #153
mrkeen wrote: post #97

Earlier quoted context omitted.

This is syntactic sugar only. No change in semantics. So I don't buy into any argument about what this change 'means'. And we all get to choose what we find ridiculous: i = i + 1 ? No it does not. Never has, never will. Connection is null? It's insane to type it as Connection then. null has type Null.

I don't understand what you are talking about. The syntactic sugar already exits before this change. That is to say, in a version f C# without the feature, you can write this: a.b?.c = foo It's not not well-formed semantically. What the change does is allow the above to be well-formed semantically. If b isn't null, then it behaves like a.b.c = foo. Otherwise, the value of foo is discarded. (Perhaps foo isn't even eva…

> The idea that there is no change in semantics, but only syntactic sugar is exactly backwards.

> The syntactic sugar already exits before this change. That is to say, in a version f C# without the feature, you can write this:

  a.b?.c = foo
You cannot.

The semantics is conditional assignment, which already exists in the language. Hence the article repeatedly bludgeoning you with pairs of code snippets - whose semantics is the same - but there is a new syntax. So maybe you could say "there's no syntax change" in the sense that "there is only additional syntax, none of the old syntax as been modified".

When you insisted this was a change in semantics, I double-checked, because this would be a huge fuckup (and would explain why you're making such a fuss about it). A difference in semantics (in this case) would mean backward-incompatibility, and would break all codebases already using the syntax a.b?.c = foo. But old codebases do not use that syntax because that syntax does not exist before 14. Old codebases already do conditional assignment, which has not changed. After 14 they will have new syntactic sugar to carry out the old semantics.

This is what sibling comment meant semantically with "Apparently you do t use if in your code?" even if his syntax ("do t") was fucked up.

> Is there any public visibility to the design decision; what alternatives were considered for the semantics and rejected?

Asked about for years I guess: https://stackoverflow.com/questions/35887106/using-the-null-... (I.e. their semantics already works, but they want a better syntax (or sugar) to carry out the same semantics.)

And the discussion: https://github.com/dotnet/csharplang/discussions/6072

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

#169

Post by bazoom42 »

saberience wrote: post #155
Metasyntactic wrote: post #130

Earlier quoted context omitted.

Hi there! Lang designer here. > More concise? Yes. Note: being more concise is not really the goal of the `?` features. The goal is actually to be more correct and clear. A core problem these features help avoid is the unfortunate situation people need to be in with null checks where they either do: if (some_expr != null) someExpr... Or, the more correct, but much more unweildy: var temp = some_expr; if (temp != null…

As a really long term C# engineer, I feel quite strongly that C# has become a harder and harder language over time, with a massive over abundance of different ways of doing the same thing, tons of new syntactic sugar, so 5 different devs can write five different ways of doing the same thing, even if it's a really simple thing! At this point, even though I've been doing .net since version 2, I get confused with what n…

The issues with null-checks are easily avoided though: Just don’t declare values as nullable.

C# grows because they add improvements but cannot remove older ways of doing things due to backwards compatibility. If you wan’t a language without so much cruft, I recommend F#.

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

#170

Post by accrual »

BoiledCabbage wrote: post #29
accrual wrote: post #6

Earlier quoted context omitted.

> I don't think it is normal to follow the flow assuming nothing has happened. I think it is for situations where the programmer wants to check a child property but the parent object may be null. If the parent is expected to be null sometimes, the syntax lets the programmer express "try to get this value, but if we can't then move on" without the boilerplate of explicitly checking null (which may be a better pattern…

Your summary is almost correct but replace where you used "get" with "set".

Thanks! Yes, mistake on my part.
Post reply on HN