Closed MadsTorgersen closed 8 years ago
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.
@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?
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:
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.
...
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 :)
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.
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.
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.