Follow-up to #1669 - per-channel dispatch concurrency

[lukebakken]

Follows-up to #1669 to restore some of the behavior introduced, and add tests.

cc @danielmarbach

[danielmarbach]

Isn't this approach way more complex compared to having the concurrency nullable like in my own original proposal?

[lukebakken]

Yes it is. I can't explain it, but I don't like that nullable value 😆 I can restore that behavior.

[danielmarbach]

Does it mean I get cake now? 🤣😂

[paulomorgado]

Yes it is. I can't explain it, but I don't like that nullable value 😆 I can restore that behavior.

What don't you like about it?

[lukebakken]

@danielmarbach thanks for your patience with me.

@paulomorgado I'm still getting used to seeing ? in C# code. As I'm sure everyone who watches the progression of the version 7 release has guessed, I have not been a C#/.NET-focused developer since 2013 😬. This release has brought me much more "in the loop" with regard to this language.

[danielmarbach]

@lukebakken absolutely no problem. I appreciate your time. The only thing I'll ask for is the same patience should I ever submit erlang stuff 😅

[paulomorgado]

@lukebakken,

@paulomorgado I'm still getting used to seeing ? in C# code. As I'm sure everyone who watches the progression of the version 7 release has guessed, I have not been a C#/.NET-focused developer since 2013 😬. This release has brought me much more "in the loop" with regard to this language.

First you find it strange, then you find it stranger. 😄

For nullable reference types, the compiler does flow analysis. You still need to validate user input, but for internal code, you can just add Debugger.Assert calls to assert everything is OK and you can rely on the compiler telling you if it may be null or not.

For nullable value types, when performance is involved, especially regarding type sizes, it's usually a bad idea to store them. But for API contracts, they are great. And if you use pattern matching when validating and using them, performance is great.