Added: C# Language Design Notes for Jul 5, 2017

[MadsTorgersen]

C# Language Design Notes for Jul 5, 2017

Triage of features in the C# 7.2 milestone. They don't all fit: which should be dropped, which should be kept, and which should be pushed out?

1. Static delegates (8.0)
2. Native int and IntPtr operators (7.X)
3. Field target (anytime)
4. Utf8 strings (8.0)
5. Slicing (7.X)
6. Blittable (7.2)
7. Ref structs (7.2)
8. Ref readonly (7.2)
9. Conditional ref (7.2)
10. Ref extensions on structs (7.2)
11. Readonly locals and params (X.X)
12. ref structs in tuples (don't)
13. Overload resolution tie breakers with long tuples (use underlying generics)

Please discuss!

[4creators]

Would like to vote for

1. Static delegates (asap) - current delegate implementation is a bad fit for any performant code
2. UTF8 strings - again critical for gains in throughput and size of code and memory - even now small change to PE file spec allowing for custom User Stream with UTF8 string would help reduce apps and runtime footprint.
3. Blittable - again due to performance gains backed by type safety
4. Ref readonly - important for several scenarios where immutability is desired - type safety check
5. Readonly locals and params - same as above
6. Native int and IntPtr/UIntPtr operators - just to get complete implementation without cast problems for arithmetic operations.

It's not on the list but generics limitations or type system issues are sprayed all around the list. IMO it is result of developer frustration with limitations of current type system and in particular with generics limitations. Fragmentation of the discussion results from the fact that average developer is not type theorist capable of writing complete, expanded type system language proposal. From this it seams that we need higher order types and constructs allowing for much more expressiveness while maintaining type safety (precisely increasing type safety). This would lead to more functional features and more expressiveness and more productivity being available for developers in C#. I would not mind if performance features will retain first class treatment in future as well.

In general I am in favor of expanding type system and type system based safety with exception of landing C# syntax in Java and Scala position where in both cases type system was proven unsound:

• Amin, Nada, and Ross Tate. "Java and scala's type systems are unsound: the existential crisis of null pointers." Proceedings of the 2016 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications. ACM, 2016.

Some of C# soundness proofs were based on syntax used in Java proofs and due to it's limitations and limited scope of proofs (limited subsets of the language syntax) it would be quite interesting if C# syntax has a sound type system verified as whole. Perhaps this same question can be asked for F# and VB as well.

[HaloFour]

@4creators

Could you elaborate on this "unsoundness" that C# (and the CLR suffers) from?

That paper seems to largely deal with JVM generics and wildcards. Anyone can tell you how fragile that entire system is. It was designed that way on purpose. Generics on the CLR are significantly different and the same problems can't be exploited due to the generic type arguments being reified and verified at runtime, not just by the compiler. Unless you can demonstrate some specific examples I don't see how the generics arguments apply.

As for the "billion dollar mistake", the C# team working on that problem, and literally just published a discussion issue based on their work. But that's not a problem that will fit in the 7.x timeframe, which is why it is not mentioned here.

[4creators]

@HaloFour I have not stated that C# (or even further CLR) is unsound in any way. The problem is that it is unproven that whole syntax is sound as proofs comprise only small subsets of the syntax containing parts of type system under proof. I have cited several articles on that problem in another post (see copied article links below) and I have stated that C# is proven to be sound. However after reading Amin's proof I am no longer sure it is the case, as proofs below are created on the narrow subsets of the language using the very some tools used in Java soundness proofs which were proven to be wrong.

• Bierman, Gavin M., et al. "Pause'n'Play: Formalizing Asynchronous C#." ECOOP. 2012.,
• Bierman, Gavin M., Erik Meijer, and Mads Torgersen. "Adding Dynamic Types to C#." ECOOP. Vol. 6183. 2010.,
• Svendsen, Kasper, Lars Birkedal, and Matthew Parkinson. "Verifying generics and delegates." European Conference on Object-Oriented Programming. Springer, Berlin, Heidelberg, 2010.,
• Kennedy, Andrew, and Don Syme. "Design and implementation of generics for the. net common language runtime." ACM SigPlan Notices. Vol. 36. No. 5. ACM, 2001.,
• Gordon, Andrew D., and Don Syme. "Typing a multi-language intermediate code." ACM SIGPLAN Notices 36.3 (2001): 248-260.,
• Yu, Dachuan, Andrew Kennedy, and Don Syme. "Formalization of generics for the. net common language runtime." ACM SIGPLAN Notices. Vol. 39. No. 1. ACM, 2004.

However, unsoundness of any syntax was not a main point of my post.

[DavidArno]

Looks like winners and losers for everyone there. Appreciate the update on the team's current plans for 7.2.

The only oddity is private protected. This seems to have disappeared off the radar completely. I'm not complaining as it's not a feature I'd ever use, but it seems a popular feature with some and so seems odd that it's almost been quietly forgotten about. Did I just miss its release in 7.1?

[orthoxerox]

A bit sad to see readonly locals and params get pushed out of 7.2. This change would greatly improve programming hygiene.

[DavidArno]

@orthoxerox,

That was the one that disappointed me too. Not so much that it's pushed out of 7.2, but that it's pushed to "X.X", rather than keeping it as "7.X" like slicing.

[4creators]

@orthoxerox @DavidArno IMO it should be 7.2 as this would eliminate a whole class of bugs.

[tannergooding]

Most of the ref features have workarounds today (at least on netcore where System.Runtime.CompilerServices.Unsafe exists), so I'm less concerned about those.

However, Static delegates in particular I'm sad won't be available until 8.0 as there doesn't exist a "reasonable" workaround to use this "feature" today.

In my existing interop code, I currently have to call Marshal.GetDelegateForFunctionPointer<T> for every entry in the unmanaged VTBL (the call itself is fairly expensive as well). This currently results in a heap allocation for each VTBL entry (this quickly gets into the hundreds, if not thousands, when dealing with things like DirectX). So not only do I have to cache the delegate (4/8 bytes) but each delegate has an internal size of 24/48 bytes (and this isn't including the heap allocation overhead or internal runtime metadata for the delegates).

This basically means that for every VTBL entry in my interop code I have a minimum 600% memory overhead and a large increased startup cost. For D3D12 interop, the ID3D12GraphicsCommandList VTBL contains 60 entries. So, just for this type alone, I have 60 allocations resulting in 1,680 additional bytes (1.6kb) of overhead (not to mention the increased GC pressure, the internal runtime overhead of the allocations, the additional lookups required to invoke each delegate, etc).

Static delegates, at least for me, cannot come fast enough.

[vcsjones]

Native int and IntPtr operators (7.X)

I assume X here means "probably after 7.2", unless there is a slim chance you're considering it for 7.1. Regardless, this feature is super important to me for interop code where arithmetic on IntPtr is painful and results in some... poor code.

[DavidArno]

@vcsjones,

Yep, v7.X means after 7.2, if there's 7.3+ releases, otherwise 8.0. What's going to be in 7.1 is now fixed as far as I know (and available for use in the VS2017 Update 3 preview releases).

... this feature is super important to me ...

The issue the team has is that every feature is super important to someone. They'll never please all the people and all that.

[vcsjones]

The issue the team has is that every feature is super important to someone. They'll never please all the people and all that.

Yep. I understand. Just trying to voice my needs to try and make that X closer to a "3" and not a "8" if possible :-).

[jnm2]

It's better to release more frequently, which necessarily means less in each release. If 8 comes fast I won't mind if stuff is pushed to 8.

[alrz]

Regarding static delegates, I think introducing ValueAction<..> and ValueFunc<..> types is too much of a hassle, might be worth it to wait for "function types" and "clr unification of types across assemblies" (#317) for a possibility of unifying these to a common feature -- just pointing out a less discussed fact that static delegate proposal in its current form needs a whole new set of types to be added to the framework.

[tannergooding]

@alrz, why does static delegates require introducting ValueAction and ValueFunc? It would certainly benefit from having those exposed, but it is not currently listed as required by the proposal.

Consumers of static delegates, in general, can benefit in their own APIs regardless of whether CoreFX exports types. Having CoreFX provide a set of standard definitions, so you don't have to have new internal types in your own library, is just a bonus (even Desktop Framework didn't get most of the Action and Func overloads until 4.0).

[Thaina]

It sad that we can't return ref struct on tuple. But can we did it somehow with other syntax?

out ref var or anonymous object reference, something like that?

What we really want is to return multiple reference of struct. It not necessary be tuple

[Mafii]

Most imporant for me are these:

1. Ref readonly (7.2)
2. Readonly locals and params (X.X)

Somewhat important, but I've never had the feeling of "I NEED THIS":

1. Ref structs (7.2)
2. Conditional ref (7.2)
3. Ref extensions on structs (7.2)

Why were Readonly locals and params pushed to X.X? They are imo a great improvement to the language in terms of self-documenting code and maintainability.

[GSPP]

When I read this list I hope that C# does not become overloaded. None of these things seem to matter in day-to-day programming very much. They seem to be targeted at library authors mostly. I trust that the C# team will not overload the language with niche concepts thereby reducing the total value of the ecosystem. (They have done a great job in the past!)

It seems to me that records are far more important than all of these features combined. Records have the potential to significantly change the style we code in. When it becomes easier to declare DTO types (using records) some functional programming ideas become far more attractive. F# feels so fluid in part because abstractions such as functions and DTOs are so easy to produce. C# has gotten more of that over the years which has been fantastic.

[tannergooding]

None of these things seem to matter in day-to-day programming very much. They seem to be targeted at library authors mostly.

@GSPP, I think that targeting library authors, as well as application authors, is a good thing.

C# has introduced a lot of features over the years that make programming things easy, but that doesn't mean that doing it is performant or memory-efficient. For example, LINQ is generally more readable, concise, and maintainable but can quickly lead to perf issues if not used properly.

There are a few features here that are niche, but almost all of them are oriented towards writing performant code or towards reducing the number of heap (GC tracked) allocations. These things probably don't matter for LOB apps, but they definitely matter and will make a significant difference for things like CoreFX, desktop/user applications, and even the compiler itself.

[gafter]

@4creators In answer to your questions: the C# type system is both undecidable and unsound. See the first answer at https://stackoverflow.com/questions/23939168/is-c-sharp-type-system-sound-and-decidable

[4creators]

@gafter Thanks for the link and answer. Are there any formal models/proofs comprising larger part of C# than those from cited articles?