C# Design Notes for Mar 18, 2015

[MadsTorgersen]

C# Design Meeting Notes for Mar 18, 2015

Agenda

In this meeting we looked over the top C# language feature requests on UserVoice to see which ones are reasonable to push on further in C# 7.

1. Non-nullable reference types (already working on them)
2. Non-nullary constructor constraints (require CLR support)
3. Support for INotifyPropertyChanged (too specific; metaprogramming?)
4. GPU and DirectX support (mostly library work; numeric constraints?)
5. Extension properties and static members (certainly interesting)
6. More code analysis (this is what Roslyn analyzers are for)
7. Extension methods in instance members (fair request, small)
8. XML comments (Not a language request)
9. Unmanaged constraint (requires CLR support)
10. Compilable strings (this is what nameof is for)
11. Mulitple returns (working on it, via tuples)
12. ISupportInitialize (too specific; hooks on object initializers?)
13. ToNullable (potentially part of nullability support)
14. Statement lambdas in expression trees (fair request, big feature!)
15. Language support for Lists, Dictionaries and Tuples (Fair; already working on tuples)

A number of these are already on the table.
#1. Non-nullable reference types

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2320188-add-non-nullable-reference-types-in-c

We're already working on this; see e.g. #1648.
#2. Non-nullary constructor constraints

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2122427-expand-generic-constraints-for-constructors

It is odd that we only support the new() constraint for empty parameter lists. In order to generalize this, however, we'd need CLR support to express it - see #420.
#3. Support for INotifyPropertyChanged

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2255378-inotifypropertychanged

This is too specific an interface to bake in special knowledge for in the language. However, we recognize the pain of having to repeat the boilerplate around this, even as we've improved the situation here a bit with C# 6.

We think that this may be better addressed with metaprogramming. While we don't have a clear story for how to support this better, in the language or compiler tool chain, we think that Roslyn in and of itself helps here.

We'll keep watching the space and the specific scenario.
#4. GPU and DirectX support

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2730068-greatly-increase-support-for-gpu-programming-in-c
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3646222-enable-hlsl-directx-and-graphics-development-tool

These are mostly library-level requests, independent of the language.

One feature that could potentially improve such libraries would be the ability to specify generic constraints that somehow express the presence of numeric operators. Being able to write generic methods, say, over anything that has a + operator, allowing + to be used directly in that method body, would certainly improve the experience of writing such code, and would prevent a lot of repetition.

Unfortunately, like other new constraints, such a numeric constraint facility would require new support from the CLR.
#5. Generalized extension members

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2242236-allow-extension-properties
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2060313-c-support-static-extension-methods-like-f

The requests for extension properties and for static extension methods are essentially special cases of a general desire to be able to more generally specify extension member versions of all kinds of function members: properties, indexers, constructors, static members - why not?

This is a reasonable request. The main problem we have is that the current scheme for extension methods doesn't easily generalize to other kinds of members. We'd need to make some very clever syntactic tricks to do this without it feeling like a complete replacement of the current syntax.

This is certainly one that we will look at further for C# 7.
#6. More code analysis

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4428274-improve-code-analysis

This feels like it is best addressed via Roslyn-based analyzers.
#7. Extension methods in non-static classes

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3359397-allow-extension-methods-to-be-defined-in-instance

We were very cautious when we first introduced extension methods, and surrounded them with a lot of restrictions. This is a well argued scenario where allowing them inside instantiable classes would enable a fluent style for private helper methods.

This seems fair enough, and we could loosen this restriction, though it's probably a relatively low priority work item.
#8. XML comments

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2709987-xml-comments-schema-customization-in-c

This is not a language suggestion.
#9. Unmanaged constraint

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4716089-unmanaged-generic-type-constraint-generic-pointe

This would be great in order to enable pointers over type parameters. However, it requires CLR support.
#10. Compilable strings

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/5592955-compliable-strings

This is mostly addressed by nameof in C# 6; it's unlikely there is basis for more language level functionality here.
#11. Mulitple returns

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2083753-return-multiple-values-from-functions-effortlessly

We're already looking at addressing this through tuples.
#12. ISupportInitialize

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2094881-add-support-for-isupportinitialize-on-object-initi

This suggestion addresses the need to perform validation upon initialization. While depending on the ISupportInitialize interface is probably too specific, it is interesting to ponder if there is a way to e.g. hook in after an object initializer has run.
#13. ToNullable

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2531917-structure-all-nullable-values

This suggestion would add a new operator to make type parameters nullable only if they are not already so.

You could certainly imagine something like this in conjunction with at least some variations of the nullability proposals we have been discussing lately.
#14. Statement lambdas in expression trees

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4255391-let-lambdas-with-a-statement-body-be-converted-to

The language today doesn't allow statement lambdas to be converted to expression trees, despite there being expression tree classes for most features. Moreover, in fact, it disallows several expression forms, including await expressions.

This would be a lovely gap to fill, especially since it would come with no conceptual overhead - more code would just work as expected. However, it is also an enormous feature to take on. We are not sure we have the weight of scenarios necessary to justify taking on the full magnitude of this.

It is also possible that we'd address a subset.
#15. Language support for Lists, Dictionaries and Tuples

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2405699-build-list-dictionary-and-tuple-into-the-language

We are already looking at tuples, and we do have it on our radar to consider language syntax for lists and dictionaries in some form. Many shapes of this feature would require a strong commitment to specific BCL types. However, you could also imagine having anonymous expression forms that target type to types that follow a given pattern.

[aluanhaddad]

Regarding item 15. I think that it would be great to have support for collection literals, but as you say this, might involve committing to specific BCL types. In my mind, this is a major drawback.
You mention a pattern based approach to allow these syntactic forms to be extensible. I think this is fantastic idea as it follows the approach that has been used for previous syntactic extensions (collection initializers, foreach, query expressions) and would give C# collection initialization expression the desired conciseness without losing generality.
The linked proposal on uservoice mentions Lists, Dictionaries, and Tuples. I think that it would be desirable to have a syntax for Sets as well.

Perhaps a type could support such syntax by defining a factory method with a certain signature.
The problem is that ambiguity would instantly arise when the union of the types in scope contained multiple types supporting a given construction syntax. One way to mitigate this would be to default to BCL types, possibly System.Collections.Generic.List<T>, System.Collections.Generic.Dictionary<T>, and System.Collections.Generic.HashSet<T>, but allow this to be overridden by some sort of using style directive. So assuming list literals used the syntax

var xs = { 1, 2, 3 };

the type of xs would be System.Collections.Generic.List<int> unless a class, say MyListLikeCollection<T>, were explicitly imported via a directive such as

using MyListLikeCollection;

in which case the type of xs would be MyListLikeCollection<int>

One possibility which seems potentially promising would be to make the system interface based such that, for a type to be targetable by a collection literal expression, it would need to implement IList<T>, IDictionary<TKey, TValue>, or ISet<T> respectively.

[axel-habermaier]

@MadsTorgersen: Concerning (4) (GPU/DirectX): This is also closely related to (9) (Unmanaged constraint) as well as destructible types, which you unfortunately have already decided not to support. Furthermore, support for function pointer types (not delegates; as far as I know, C++/CLI is the only .NET language to support them) and the calli instruction would greatly help here. Libraries such as SharpDX (DirectX) and OpenTK (OpenGL) usually rely on post-build assembly rewriting using Mono.Cecil to inject the appropriate calli instructions. As Eric Lippert has pointed out in an old Codeplex thread, he once came up with a design for such a feature. Would you maybe share it with the community, so that we can discuss it? Maybe it could be community-implemented?

[dsaf]

I wish other teams at Microsoft would do the same. There is a lot of top requests without any definitive feedback.

On the other hand, is the popularity of a User Voice suggestion meaningful? Most of the people are voting on the suggestions that are at the top. It's very similar to App Store or any other such list in this respect.

@MadsTorgersen

'11'. Mulitple returns
We're already looking at addressing this through tuples.

Would this mean a strong commitment to Tuple<...>? In one of my projects I decided to implement my own version as a struct, which is not unreasonable at all:

http://stackoverflow.com/questions/2410710/why-is-the-new-tuple-type-in-net-4-0-a-reference-type-class-and-not-a-value-t

It also implemented an extra interface I wanted, which is also not unreasonable. This is a real issue and is similar to one in '15'.

'15'. Language support for Lists, Dictionaries and Tuples
Many shapes of this feature would require a strong commitment to specific BCL types.

Maybe type argument inference would be sufficient? #1470

Alternatively:

However, you could also imagine having anonymous expression forms that target type to types that follow a given pattern.

Would that eliminate potential clashes though? Maybe there should be a way of importing a specific implementation:

using System.Collections.Generic.LinkedList;
...
var listOne = { "a", "b", "c" }; //Uses imported LinkedList;
var lsitTwo = new List { "a", "b", "c" }; //Uses explicit List<T> with stronger inference for type argument.
...

[nietras]

With regard to item 9. why does this involve changing the CLR if F# can already support this? See under
https://msdn.microsoft.com/en-us/library/vstudio/dd233203%28v=vs.100%29.aspx , however I assume this does not allow making pointers still.

Additional, for further input on why this is very much needed see: http://www.codingmurmur.com/2014/07/vote-for-unmanaged-generic-type.html

So if the CLR needs changes please please do that :)

[gafter]

Design notes have been archived at https://github.com/dotnet/roslyn/blob/future/docs/designNotes/2015-03-18%20C%23%20Design%20Meeting.md but discussion can continue here.