LDM Notes for May 1st, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-05-01.md

Agenda

• Fixed Size Buffers
• lock statement improvements

[TahirAhmadov]

Re. lock, I'm confused - so are any changes going to be made to the language at this point or not?

[TahirAhmadov]

@jnm2 That's fine, my thought process here is that C# shouldn't even begin experimenting before the runtime has a plan for the entire vertical.
If the plan is to slowly convert lock to use the new "surface area" lock types, that's fine, I can live that (in fact, I can see benefits in that approach). The problem is we don't know what the plan is; it looks like there is no plan, other than "we'll make minor language changes in response to the runtime team's introduction of new types".

[jnm2]

The C# design team's input is potentially quite valuable to the the runtime team as part of their own design process. Can you explain the issue you have in mind with this?

[TahirAhmadov]

My concern is with this sentence:

An open question is whether we want to convince people to avoid monitor-based locks entirely; that seems like it would be best driven by the runtime, rather than the language design team.

That gives me absolutely no confidence whether I should start using the new locking types, what's going to happen in the future with Monitor the type, lockability of all objects, etc. (even if Lock is added to .NET vNext and lock uses it in C# vNext).

On the other hand, if locking type(s) were added, specifically aimed at using, I'd be perfectly happy using those in a few places to look at how they perform, as part of an ecosystem-wide experiment.

My confidence level aside, what if the surface area is not sufficient for whatever reason? Now we're "locked into" lock (haha) language construct, and changing it becomes more difficult.

[CyrusNajmabadi]

That gives me absolutely no confidence

This is all an experiment currently. I'm not sure what you're looking for :-)

Our position simply is that we feel like if the runtime modernizes locks that we would bring the language along with that, that's all.

[HaloFour]

Our position simply is that we feel like if the runtime modernizes locks that we would bring the language along with that, that's all.

I think that's a reasonable position. Monitor-based locking as a feature baked into every reference always felt like a mistake copied from Java to me. If the intent is to explore moving towards a more intentional design that feels like a good plan. However, my concern is that Monitor locks are so entrenched in the runtime and ecosystem that this will be impractical and that we'll be left in some halfway state.

[TonyValenti]

Is there I link I can read about the lock experiment in more detail?

Also, I would like it if lock had a short form like using does.

lock objlock;

[333fred]

dotnet/runtime#34812

We did briefly mention the short form, but afaik there's no championed proposal for it.

[orthoxerox]

I remember how confused I was by nullable jagged arrays when I had to consciously realize that the innermost brackets mean the outermost array. But I am confused again.

This is then complicated further by nullability: a non-null regular array of 4 element int nullable arrays would be int[]?[4]

Isn't that a nullable regular array of 4-element non-null arrays of non-null ints?

[CyrusNajmabadi]

has already blown several minds of C# enthusiasts

I mean... the same was true when we did nullable originally. My point is that it didn't turn out to be a substantial problem in practice. It's just a wart, not a foot gun.

[HaloFour]

But has also been this way for several years now

Longer than that if you consider that NVTs initially set the tone back in C# 2.0 with int?[][]. NRTs didn't really have anywhere else to go.

[333fred]

Gah!

string[]?[] arr2x1n = new string[2][];
arr2x1n[0] = null;
arr2x1n[1] = new string[] { "2,1" };

So, it's nullability from right to left and lengths from left to right. It's not just a footgun, it's a GAU-8 footautocannon.

Yup. @colejohnson66, this is what I mean. C# very unfortunately copied C here, and the syntax does not work how you think it does. And, imo, it's one thing if you can only observe this inconsistency in a new, it's quite another if you can observe it in any type expression.

[colejohnson66]

In that case, maybe const generics should become a thing. Afterwards, instead of shoehorning fixed size buffers into array syntax, we'd use a Buffer<byte, 4>? Feels clunky, but it'd be more understandable how nesting works.

[Joe4evr]

@colejohnson66 You're going to make @Sergio0694 happy with that. 🤣