Improving C# Memory Safety
devblogs.microsoft.com
Improving C# Memory Safety
1–10 of 47 posts
Re: Improving C# Memory Safety
#2Most likely a side effect related to Windows team finally giving some C# love, instead of COM and C++, given the comparisons between C# 16 with Rust and Swift in a few article sections.
Re: Improving C# Memory Safety
#3What you can do in C# today is convert any unsafe pointer to Span whenever you get your hands on it, and pass around slices. You can still drop down to ‘fixed’ when it turns out you need it for performance.
Re: Improving C# Memory Safety
#4Most likely a side effect related to Windows team finally giving some C# love, instead of COM and C++, given the comparisons between C# 16 with Rust and Swift in a few article sections.
The Windows team is talking to DevDiv again? Satan's putting on his ice skates right now.
Re: Improving C# Memory Safety
#5Most likely a side effect related to Windows team finally giving some C# love, instead of COM and C++, given the comparisons between C# 16 with Rust and Swift in a few article sections.
The Windows team is talking to DevDiv again? Satan's putting on his ice skates right now.
One can only hope.
C++/WinRT is in maintenance, and you will notice the WinUI 3.0 does most of their demos, and gallery with C#.
Re: Improving C# Memory Safety
#6> The unsafe keyword is being redesigned
OK, I see a lot of C# code often and over a long time.
I see the "unsafe" keyword used approximately never.
I'm sure that this is useful for some cases. But not everyday things for most of us. If we did use it, it would be carefully isolated in a library for a specific purpose.
Re: Improving C# Memory Safety
#7> The unsafe keyword is being redesigned OK, I see a lot of C# code often and over a long time. I see the "unsafe" keyword used approximately never. I'm sure that this is useful for some cases. But not everyday things for most of us. If we did use it, it would be carefully isolated in a library for a specific purpose.
Many of us use it in scenarios where others would write a blog post about a rewrite in Rust, C++ or whatever.
CLR was designed to support languages like C++, yet many don't learn the knobs.
Re: Improving C# Memory Safety
#8> The unsafe keyword is being redesigned OK, I see a lot of C# code often and over a long time. I see the "unsafe" keyword used approximately never. I'm sure that this is useful for some cases. But not everyday things for most of us. If we did use it, it would be carefully isolated in a library for a specific purpose.
This moves C# to a more modern systematic understanding of what this keyword is for, but it'll remain very rare in C# the same way it's rare in Rust, and presumably in Swift.
The choice of keyword "unsafe" is partly psychological. Turns out if you called this exact same feature "trusted" or whatever the programmers don't have the appropriate feelings about it. They want to write trusted code, they don't want to write unsafe code, so making them write the keyword "unsafe" provides that psychological disincentive.
Re: Improving C# Memory Safety
#9> The unsafe keyword is being redesigned OK, I see a lot of C# code often and over a long time. I see the "unsafe" keyword used approximately never. I'm sure that this is useful for some cases. But not everyday things for most of us. If we did use it, it would be carefully isolated in a library for a specific purpose.
C# is like Rust in the sense that a regular (web, desktop, etc.) developer probably won’t need unsafe, but it’s useful for lower-level work in libraries and CLI tools, especially where performance is important.
Re: Improving C# Memory Safety
#10> The unsafe keyword is being redesigned OK, I see a lot of C# code often and over a long time. I see the "unsafe" keyword used approximately never. I'm sure that this is useful for some cases. But not everyday things for most of us. If we did use it, it would be carefully isolated in a library for a specific purpose.
Around here C# is only really used at stagnant middle sized companies with horrible code bases. The sort where the company follow Uncle Bob religiously, while completely misunderstanding everything Uncle Bob ever said. Doesn't mean the language (and it's runtime) can't be good.