LDM Notes for January 26th, 2026

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2026/LDM-2026-01-26.md

Agenda

• Alternative syntax for caller-unsafe

[GeeLaw]

user of a field/property must be in an unsafe context.

This seems to go against relaxation of unsafe: Declaring/initializing/acquiring/adding/subtracting/assigning a pointer is not unsafe, dereferencing one is.

For the same reason, reading/writing to a field shouldn't require an unsafe context.

• If the field is of pointer type, then dereferencing it is guarded by dereferencing rule.
• If the field is of reference/value type, then calling its methods can be unsafe, but reading/copying it around is not.
• Either way, if a pointer/object has been obtained, then assigning it to the field shouldn't be unsafe, just like assigning a pointer isn't unsafe. If the new value needs to be obtained unsafely, unsafe would be needed in the obtainment code.

[333fred]

For the same reason, reading/writing to a field shouldn't require an unsafe context.

Untrue. If a field or property is expected to be a certain value, and the user of that API is expected to follow a contract or the resulting usage of that field or property would cause a memory error, then the field or property should be marked as unsafe. We are not saying that pointer math is inherently safe; what we're saying is that pointer math is not inherently unsafe. The guidance is still to surround the actual block of unsafety appropriately, so that future readers eyes will be drawn to the part that needs careful scrutiny of inputs and outputs. Likely, most of the time pointer math will still be in the unsafe block, and for good reason. But it doesn't have to be if there is good reason for it not to be so, unlike today where it must be in the block and unnecessarily extends the block further than the area of real concern.

[GeeLaw]

I tend to not edit part of the quotation so that people can Ctrl+F to the context. I was only talking about fields, not properties. Properties are methods/method pairs so I don't have any objection. Moreover, it's perfectly reasonable and common for a property getter to not require unsafe context and the setter to require it --- if a value satisfies its invariants, then modifying it part by part could (temporarily) violate the invariants, but reading from it doesn't.

Compare this with fields. There's no current proposal to separate requires-unsafe-ness of reading from/writing to a field. Marking a field as requires-unsafe would then require unsafe context for both reading and writing, which could be very unergonomic. The usual recommended way to resolve this is, of course, to make the field private and provide a property, whose getter/setter can then be marked as requires-unsafe as appropriate.

In addition, one shall ask whether a ref variable/parameter can be marked so that inside the method body, writing to it requires unsafe context, whether an array variable can be marked so that accessing its elements requires unsafe context. Why are those needed? Because assigning to references to value-type variables (1) is effectively assigning every field, hence could assign a requires-unsafe field, (2) could tear hence cause memory safety errors. Why stop at field level, then?

We are not saying that pointer math is inherently safe; what we're saying is that pointer math is not inherently unsafe.

This unnecessarily complicates the mental model. Something is either provably safe (I'm taking this to mean "if nothing ever is done after this operation, the CLR remains consistent", and "provable" is defined by C# compiler logic) or not provably safe. "Unsafe" should just mean the latter.

The guidance is still to surround the actual block of unsafety appropriately

I agree that a cohesive block of unsafe manipulation should be marked as unsafe as a whole, but that's unrelated to my objection. The major reason is that (proof-)reading a block of unsafe is much easier than a block of code with unsafe scattered everywhere.

[333fred]

Marking a field as requires-unsafe would then require unsafe context for both reading and writing, which could be very unergonomic.

This isn't a particular problem, as there's no way to generally make the field only writable, and the user would have to explicitly mark the field as unsafe anyway. Speculative questions about ergonomics doesn't seem relevant to a thing that is opt-in.

In addition, one shall ask whether a ref variable/parameter can be marked so that inside the method body, writing to it requires unsafe context, whether an array variable can be marked so that accessing its elements requires unsafe context.

So far, that hasn't been a thing the libraries and runtime team has asked for, while unsafe fields explicitly have been requested. If that ends up being a scenario that needs to be addressed, we can certainly look at extending RequiresUnsafe at that point in time. Until then, though, we need to meet the scenarios that have been identified.

[huoyaoyuan]

If caller-unsafe were just an attribute, it would be effectively the same as shipping an analyzer; it wouldn't feel like part of the language.

For nullability, there are also a bunch of attributes that are directly integrated into the language. The unsafe classification doesn't seem to be as straight like nullable references. What if we want to categorize the unsafe-ness in the future? Attribute feels more extensible, but not as complex as generic constraints.

This has implications for the syntax design: having both unsafe at the method level and [RequiresUnsafe] on the same member is effectively incorrect, you probably never want both.

What about wrapper methods that transforms the parameters of a core [RequiresUnsafe] method?

When unsafe is at the method level, it suppresses all warnings internally, making it impossible to audit which specific operations are unsafe.

It's seamless for transforming existing codebase, since unsafe on method is quite popular. The original proposal to change the meaning of method-level unsafe is too breaking and would require a project to be updated in monolithic.

[MgSam]

Glad to see you’re going with an attribute. Changing existing syntax to have a different meaning would’ve been a disaster.

I don’t think using an attribute makes C# “feel” less memory safe. Unsafe is already an extremely niche feature used on a tiny fraction of C# codebases.

Also designing languages based on human readability is probably in its twilight anyhow. LLMs will be reading and writing almost all code before long.

[AartBluestoke]

I would argue that llms require clear and unambiguous syntax- the design considerations for llm understanding and human understanding are not that far apart.
Ai would be susceptible to c# using syntax similar to other languages to mean something different here, or for the same syntax to mean something different based on context, especially context being the current line.
Humans struggle with symbol dense and word poor representations of complex concepts.
Both struggle where context is implicit.
What did foo(1000,1000); do? We can't tell. What does foo(delay=1000,duration=1000); do? Still no idea, but now we know it is some type of timing function. making context explicit helps understanding.