Partager via

What do you want in the next version of C#/VS (part 2)

  • Article

I went through the entire list and collected all the features that people requested. I then filtered that down to things that aren't in our beta1 release. I've also left out things that i didn't understand, asked questions about, and didn't get a response on. Feel free to raise those issues again so they don't get lost. I also broke up the requests into different areas to help explain who works on these issues. I also may have just missed a couple, don't take that to mean that I don't want it! (read below for some instructions).

Things that the C# team has control over

  • Better control over completion list (sorting and filtering). 
  • Better syntax for casting
  • Support for mixins
  • Spell-checking
  • User filtered catch handler. i'd like examples of why this is useful.
  • Expose the compiler through a managed API
  • Expose the refactoring engine
  • Nice inline array syntax
  • Better enum checking
  • Warnings for certain goto behavior
  • Better intellisense for indexers, operators and user defined conversions
  • Better support for telling you when you're using a disposable type unsafely
  • Automatic constructor stub generation: including making base calls and setting fields
  • Better code generation in general: generate field/property/constructor/class/etc.
  • Better control over all code generation.  (include /// generation)
  • Better support for nesting other languages in C# (like regexps and xml). Either through direct support in the language, or direct support through the tools
  • Find code duplication
  • More flexible interface implementation support
  • Top level functions
  • Tuples
  • Preconditions/Postconditions
  • Special constructs for asynchronous operation.
  • Nicer syntax for anonymous delegates
  • "using SomeClass" to allow direct access to static members in that class
  • Generic properties
  • Allow for properties to have a private backing store.
  • An easy way to collapse only comments
  • Exception filtering
  • Way to use events without having to check for null
  • Haikus

Things that the C# team can work with other teams to implement

  • New syntax + unification of value/class/array types using the + ? ! * syntax.  (See Orion's excellent posts on this): C# + CLR
  • Edit and continue. C# + the runtime
  • Make VB = C#.  Parity on tools and in the language: C# + VB
  • Covariant return types: C# + CLR
  • Non-null types: C# + CLR
  • Generic parameter lists of variable length: C# + CLR
  • Better operators. (on interfaces, virtual, type parameters, etc.). Allow user defined operators: `intersection`: C# + CLR
  • More control over fonts and colors in different regions in the file.: C# + Core editor team
  • Better constraints on generic type parameters: C# + CLR
  • Better incremental find: C# + Core editor
  • Attributes on smaller grained elements (code blocks, etc.): C# + CLR
  • Const support: C# + CLR
  • Better way to refer to method set in documentation.  i.e. some way to point to all methods called Foo
  • Haikus

Things that are for other teams to implement.

  • Integration of analysis tools (like FxCop): Research
  • Simpler debugging with threads: Debugger team
  • Managed interface to the profiling APIs: CLR
  • Notifications when an exception is thrown: CLR
  • Better tools support for understanding the modules loaded in fusion: CLR
  • Better MSI support: Not sure :-(   . Lots of feedback on this. Managed interface.  Better debugging.
  • Better Add-ins support: VSIP program
  • Better mock object support: CLR + Team system
  • IntPtr operators: Base class libraries
  • Much better docs. Diagrams, complexity (see ATs post) :-) : Doc teams
  • Better enforcement of FxCop rules on MS provided types. No more dead-ends in the frameworks: Base class libraries
  • Easier discoverability of key-bindings: Core editor
  • Better plugin support for unit testing engines: Team system
  • Allow any .Net langauge (including C#) to write VS macros in: VS Automation team.
  • Haikus

Now I'd like you to vote/rank on this to get some kind of numbers of how you feel about this. But not yet. I want to make sure that the list is correct/complete before continuing. Tell me if I'm missing something. If you'd like something broken up into multiple features let me know. If you also have better suggestions for the title/description, feel free to contribute those as well.

Hrmm... I forgot to include Edit&Continue (C# + Debugger + CLR teams). Probably missed it because no one really brought it up in the feedback. But for the few of you who did, you might find Jay's take on it. Specifically: "Here's the strongest statement I can make: We're committed to getting C# Edit and Continue into the hands of our users as soon as we can, without compromising all the other commitments we've made."

Comments

  • Anonymous
    June 21, 2004
  1. The major pitfall of the current implementation of generics is their inability to handle operators, making them unusable for many cases of generic programming. Are any plans with mixins (i think they will be at Orcas) to cover this ?


    2) An attribute (or a keyword) could be created that disables the check for nullabilty at JIT time.

    in that case Length could be implemented as

    [DontCheckForNull]
    public int Length {
    get {
    return this == null ? 0 : InternalLength();
    }
    }

    and

    string a = null;
    Console.WriteLine( a.Length );
    will print 0 and will not raise an exception
  • Anonymous
    June 21, 2004
    I didn't grok it in the list above. If I missed, just ignore this.

    Automatic null checking on delegates (don't throw an exception when invoking a delegate and it's null)
  • Anonymous
    June 22, 2004
    I missed the first post, and I don't know if this is already on the table, but I'd like to toss in better Intellisense in general. Coming from VB.Net, I find myself missing how eager the VB.Net Intellisense is -- for instance, if you type

    DialogResult dr =

    As soon as you hit that =, VB.Net pops up the autocomplete with DialogResult. already filled in -- all you have to type is Yes, or No, or whatever. C#'s Intellisense doesn't do this, and it irks me. :)

    I would just urge whoever is responsible for C# Intellisense to go write in VB.Net for a week or so, and do it the same way. It's a small thing, but it really adds up both in terms of programmer irritation and time saved.
  • Anonymous
    June 22, 2004
    Better enforcement of FxCop rules on MS provided types. No more dead-ends in the frameworks: Base class libraries

    FxCop rules are just a means to and end. The goal is to ensure the framework/BCL is extensible by default. Any sealed classes, any non-virtual and non-interface methods must be justified.

    'course, it would be nice to be able to have a tool which would "liberate" a class, turning it, and references to it, into an inteface and references to an interface. That would provide for backwards "compatability" :)
  • Anonymous
    June 22, 2004
    I don't see optional parameters and named indexers. Is this something you already have in C# 2.0? If so, great!
  • Anonymous
    June 22, 2004
    The comment has been removed
  • Anonymous
    June 22, 2004
    The comment has been removed
  • Anonymous
    June 22, 2004
    The eventual elimination of arrays and the conversion of variables to set semantics along with the ability to operate on a set of objects.

    This goes a long way to simplifying code. Instead of having to iterate through every array, I can simply pass the array/set to the same method I pass the single instance.

    I.e.

    string! myString = "Hi!";
    string* myStrings = new string* { "How goes it?", "I'm fine thank you." }

    myString = myString.ToLower();
    myStrings = myStrings.ToLower();

    After that code is run, myString would be equal to "hi!" and myStrings would be equal to { "how goes it?", "i'm fine thank you" }.

    But ToLower wouldn't have to be written twice. The signature would be

    string ToLower( string s );

    you'll notice the lack of ?+! which means that whatever type goes in, is the same type that goes out. The language will take care of the iteration accross the set.

    Also you could write something to sum something and get

    int? Sum( int     values );
    int! Sum( int+ values );

    The above points out that if you pass in a nullable set, you get a nullable int. If you pass in a non-nullable set, you get a non-nullable int in return. This of course would be converted using generics to generalize the process.

    It just makes for a much simpler system. It would remove about 90% of all for loops I write.

    Orion Adrian
  • Anonymous
    June 22, 2004
    Eric: We've added automatic enum preselection in C# 2005. Any other VB'isms you want?
  • Anonymous
    June 22, 2004
    Kavan: Optional parameters and named parameters are part of "VB = C#"
  • Anonymous
    June 22, 2004
    Orion: Is int* a list, a collection, or a set?

    Are there built in operations for maps?
  • Anonymous
    June 22, 2004
    OMer: Thanks! I'll add those tonight.
  • Anonymous
    June 22, 2004
    "Expose the compiler through a managed API"

    Is this beyond what you can currently do with the System.CodeDom and Microsoft.CSharp namespaces? I've been playing around with them lately, and they do a pretty good job of giving access to the C# compiler from .NET code.
  • Anonymous
    June 22, 2004
    The comment has been removed
  • Anonymous
    June 22, 2004
    Daniel: We did look at it. But found that it was too small to justify a langauge change. We even demoed it at our SDR conference and all the devs there were pretty much of the mentality of: "this is so insignificant in my coding cycle that this would gain me all of 0.000001 improvement in coding". Because of that we felt that our efforts were better suited to providing more substantial improvements.
  • Anonymous
    June 22, 2004
    Cyrus: Optional parameters and named parameters are not "VB = C#". This is "C# >= CLS". If you don't add support to consume this then you're making C# second rate citizen when consuming CLS compliant code.
  • Anonymous
    June 22, 2004
    Shouldn't copy/paste. I mean optional parameters and named indexers.
  • Anonymous
    June 22, 2004
    The comment has been removed
  • Anonymous
    June 22, 2004
    Kavan: C# can consume those just fine.

    Optional parameters are a language feature to make consumption nicer on the user.

    However, that said. All examples I've seen with optional parameters have been indicative of a poor coding style where a better design woudl have made the issue irrelevant. Can you give me an example where you would like to see optional parameters?
  • Anonymous
    June 22, 2004
    Cleve: Perf should never be the first concern :-)

    Who knows, maybe by simplifying the language we can make things faster! That's certainly been the case with certain aspects vs C++. Because we know so much more we can optimizise better.

    Orion: How do you disintinguish between operations you want to perform on the set (like length/count) and operations you want to be lifted up onto all constituent members.

    Also, can you give more examples? They go a long way in pitching an idea like this.
  • Anonymous
    June 22, 2004
    Daniel: Note. My comment was referring to null checks on events.
  • Anonymous
    June 22, 2004
    The comment has been removed
  • Anonymous
    June 22, 2004
    Cyrus: I assume you are talking about raise accessors here. I can see its minor, but I think it would help with null checks. Witha raise you would just call MyEvent(a,b) and let the compiler generate a raise accessor like(single thread safe only):

    raise
    {
    if (DelegateField != null)
    DelegateField(a,b);
    }

    It doesn't remove the check, but it removes it from user awareness of them. Also, while the raise accessor is only optional in the spec, it is there and it would be nice if the langauge atleast consumed them. It would make it easier to write code that works with MC++, for example, which does support raise

    Kaven: Although I could be wrong, I don't believe the CLS demands consumption of default values. Infact if memory serves the spec doesn't even explicitly define the behavior of default values, they are simply metadata...no more. A compiler is free to use them or not.

    I'm not confident that named indexers are defined in the CLS either, do you have a link that shows they are?
  • Anonymous
    June 22, 2004
    Geoff: That's a fantastic idea!! no clue how I'd do it, and it runs the risk of becoming annoying really quickly.

    One way to make it useful would be to expose more and more stuff ot FxCop (so that it could do deel semantic analysis), and then have FxCop always running against your code. So you'd get immediate feedback on your coding style.

    I think that would be very very cool
  • Anonymous
    June 22, 2004
    The comment has been removed
  • Anonymous
    June 22, 2004
    I know C# can consume named indexers, but it's not elegant. Typing Class.get_Property(index) and Class.set_Property(index, value) kind of kills the whole benefit of properties. I wonder how you'd like to call Point.get_X() and Point.set_X(value).

    The reason I see optional parameters beneficial is to reduce the clutter you get otherwise with overloads. I've seen many libraries where you have tons of overloads just to handle something you could do with one or two overloads with optional parameters. I find such methods very unfriendly because it takes a lot of time to browse through all of them with intellisense just to find the one you need.
  • Anonymous
    June 22, 2004
    Kaven: I agree. And I would say that those libraries are pretty poorly designed. :)
    I'm goign to be talking later on about how we feel about adding features that seemed to get abused and end up causing people to produce poorer designs.

    We take that sort of thing very seriously and are extremely hesitant about adding them into the language.
  • Anonymous
    June 22, 2004
    Cyrus: There's only a few things that I want to do directly on an array. Generally I just want to get its size and that's it. Copying semantics should be inherent to the language. Why is it that copying a variable and copying an array are completely different processes.

    As to collections, versus lists, versus sets. All three are sets. I've already mentioned what the fundamental differences between the three.

    A collection is a set that doesn't retain order and isn't associative. A list is an associative set where an index serves as key. Either way you look at it, it comes down the same basic concept.

    My point is given the relatively small number of basic data structures the CLR should handle all of them.

    Also remember that a large number of data structures accomplish the same goal but are designed to be faster at one aspect or another (e.g. insertion/deletion versus search). This really isn't my concern as a programmer. I shouldn't have both a linked list and an array. A profiler should look at the performance information and make that decision for me.

    So basically all we're worried about is sets and graphs (also associative sets). Other structures like stack and queue just limit how you interact with the internal data.

    So what we have is sets and associative sets; we can add keywords to change the behavior of the set or graph. For instance we can get set versus multiset using a unique keyword. We can distinguish an indexed set with an indexed keyword. These would accomplish the same things that the various ICollection, IList, IDictionary and IEnumerable interfaces do.

    What it comes down to is a simple request. When I operate on variables, I don't care if I'm working on an array, a collection or a list or a variable with a single value. I want the function calls to take both. Why do I need to call for and for-each 8,000 times in my code when all I want to do is do the same operation on all the items in the array.

    So if for some reason you need to operate on the array and not on the contents of the array, make a helper class (like Array) that has static methods that takes the array and returns the appropriate data. Or you could use a set of keywords like sizeof() that would return the appropriate data.

    If this isn't enough let me know.

    Orion Adrian
  • Anonymous
    June 22, 2004
    Orion: "What it comes down to is a simple request." "A profiler should look at the performance information and make that decision for me. "

    Not very simple at all :-)

    Also when you talk about uniqueness what do you mean by that? Reference equality? ".Equals" equality?

    "Why do I need to call for and for-each 8,000 times in my code when all I want to do is do the same operation on all the items in the array. "

    My initial reaction would be "because it's very little overhead to type foreach, and it allows for an extensible collections model".

    I'm not sure how you add extensibility to this system. Would it be possible to say: "right now a set should be implemented by a LinkedHashSet?"

    Is it possible to express that these collections are threadsafe or readonly?

    There are a lot of issues here that I'm trying to understand. And while the idea is interesting, the goal of removing "foreach" probably wouldn't justify the large language change and support necessary in the CLR to do this.
  • Anonymous
    June 22, 2004
    I'm also trying to reconcile these issues.

    Right now as a programmer, I have to make decisions based on performance. I'm not just worried about making my algorithms work, but I also have to make sure they perform.

    While performance is a nice goal, very few programmers will ever be as good as a profiler and a good compiler. Plus the compiler and the profiler have to be written once and maintained versus the billions of lines of code compiled with the compiler.

    I also want consistency with variables. Why does an array work so differently than a non-array variable? This is especially a concern when dealing with relational and XML storage.

    All I know is that arrays have been a source of headaches now for years. While it's gotten better over the years, it's still an issue. Why can't I simply cast an array from one type to another the same way I do other basic types? Also if for some reason I change my data structure from a singular type to an array of the same type, I now have to change code; why?

    While functional and list-based language aren't particularly liked they do have things to teach us. I think a OO based langauge with a type system inspired by functional and list-based languages would be a great solution.

    Orion Adrian
  • Anonymous
    June 22, 2004
    Orion: AFAIK a profiler is worthless without a human involved to get the data back, understand it, and to feed that data back into fixing up the code.

    While I would love to have a panacea where one can just use sets and have the system figure this out automatically, I am also trying to figure out what can be done in the limited amount of time we have.

    Don't get me wrong. I am incredibly interested in this idea. But there's a lot to understand here and it could be an incredible waste if we spent a lot of time on this only to realize that no-one would use it because some of these issues we couldn't solve.

    BTW: I agree on takign the best of OO/Functional languages as well
  • Anonymous
    June 22, 2004
    Cyrus: I know this won't get around to this cycle, but I figured it was better to do it now and not when you ask this question again for VS 20XX.

    Orion Adrian
  • Anonymous
    June 22, 2004
    Cyrus: Optional parameters are a language feature to make consumption nicer on the user.

    However, that said. All examples I've seen with optional parameters have been indicative of a poor coding style where a better design woudl have made the issue irrelevant. Can you give me an example where you would like to see optional parameters?

    Cleve: Interacting with the Word object model. Have you seen how many parameters some of those methods have? Insane. I agree it is probably neccessary because of bad design. But bad design happens (cough: Word object model) and sometimes you have to deal with it.
  • Anonymous
    June 22, 2004
    Cleve: I'm aware of the WOM. I even blogged about it while i was at tech-ed. That said, I think that reiterates my initial point. Because this feature existed a pretty bad design was able to be introduced. We're worried that if we add this feature then more APIs like this will be created. We don't think that just because someone else made a mistake that everyone should then suffer.

    Hopefully there will be a much nicer object model out for office soon.
  • Anonymous
    June 22, 2004
    Orion: "I know this won't get around to this cycle, but I figured it was better to do it now and not when you ask this question again for VS 20XX.

    Orion Adrian "

    Keep it coming :-)
  • Anonymous
    June 22, 2004
    I'd like to see the following:
    you define an interface with XML comments. When you implement that interface in a class, the editor stubs that interface out. What I'd like to see is that the editor places the XML comments defined with the interface definition with the stub code, so I don't have to copy/paste all the XML comments over.

    Same for abstract methods. :)
  • Anonymous
    June 22, 2004
    Frans: If we do that, then you need to maintain the xml doc comment on both the interface and the class. If you don't place it on the class, then it will inherit the one on the itnerface. You can then change the docs once instead of needing to find all inheriting classes
  • Anonymous
    June 22, 2004
    I know this is C# based but I haven't found a comparable VB.NET blog yet - please can you get the VB.NET team to generate property Set templates with a camel-cased signature - i.e. Set(ByVal value As ...) instead of Set(ByVal Value As ...). I've just seen a screen shot that shows it hasn't been fixed yet :-( http://msdn.microsoft.com/library/en-us/dnvs05/html/vbnet2005_preview-fig7.gif
  • Anonymous
    June 22, 2004
    Cyrus,

    I mentioned this before and I hope you still have time to add this to the list...

    Ability to set the foreground/background colors for different #regions so that one can easily tell when one is within a given #region.

    Another way of presenting this info would be to add the region name somewhere in the status bar to indicate where in the code you are at.

  • Anonymous
    June 22, 2004
    David: It's in the list. :-)

    Under the things we would work with other teams with.
  • Anonymous
    June 22, 2004
    Pascal-like pure enumerations and array indexing by them. Let me explain.

    In Pascal, enums are ordinals with sequential values, unlike C# where enums are just const ints in disguise.

    Why would I want this? For compile-time checking and elegant handling of different cases, that's why. When I use enums in Pascal, I can create arrays indexed by these enums. When I add another value to an enum, the compiler will immediately pick up where I need to add a value to an initialisation list (Pascal syntax):

    type
    Colour = ( red, green ) ;

    ... somewhere else in a code file far far away...

    var
    MyColours : array[ Colour ] of boolean = ( true, false ) ;

    Now, if I modify the declaration of Colour:

    type
    Colour = ( red, green, blue ) ;

    I'll get a compiler error on MyColours because I need to add another element to the array initialisation, and anywhere else I've used the type to index arrays like this.

    It's very useful when you want to switch into a set of delegates, say, without using an ugly and slow case statement. Pseudo-code:

    var
    MyChoices : array[ Colour ] of MyDelegate ;

    in the code I can write:

    var
    aDelegate : MyDelegate ;
    begin
    aDelegate = MyChoices[ aColour ] ;
    aDelegate() ;

    I find that I'm frequently using enums and I want to switch on the value, so an array is the obvious way to do it.

    If I do something like this in C#, the only errors I get are runtime errors. This would probably be difficult in C#, since all arrays are dynamic and an enum-indexed array effectively has fixed bounds (assuming you'd also add support for a "pure" sequential enum).
  • Anonymous
    June 22, 2004
    "Eric: We've added automatic enum preselection in C# 2005. Any other VB'isms you want?"

    Excellent. :)

    As for other VBisms, just the eagerness of the VB intellisense in general. i.e., right now C#'s intellisense is very case sensitive; typing system. gives you nothing; you have to type System. to get intellisense. This seems like something that may be partially addressed by the new smart tags (you discuss in a later post), but having to stop, grab my mouse, and click on a smart tag to correct case is a mood-killer, so I hope the intellisense will be somewhat more forgiving too (at least in the case where there is only one correct answer; i.e. it's easy to figure out that "system" should be System; however, in the case where I've declared MyClass myClass; then I don't expect intellisense to be as forgiving on case sensitivity).
  • Anonymous
    June 23, 2004
    The comment has been removed
  • Anonymous
    June 23, 2004
    I have a real example of this in one of my class libraries:

    try
    {
    someMethodInfo.Invoke(someObject, null);
    }
    catch (TargetInvocationException ex)
    {
    if (ex.InnerException is MyActualException)
    {
    //Do something
    }
    else
    {
    throw;
    }
    }

    It would be nicer to do something like this:

    try
    {
    someMethodInfo.Invoke(someObject, null);
    }
    catch (TargetInvocationException ex where ex.InnerException is MyActualException)
    {
    //Do something
    }
  • Anonymous
    June 23, 2004
    You should check out my view of where IDEs are heading in the next three years, because I think that C# team may be in for a surprise and catching up, if they aren't careful.

    http://wesnerm.blogs.com/net_undocumented/2004/06/whidbey_may_mis.html

    and

    http://wesnerm.blogs.com/net_undocumented/2004/06/graphical_sourc.html

    I am posting it here because you may not be looking at your earlier posts.
  • Anonymous
    June 23, 2004
    Cyrus, I disagree with your leaving out optional/default parameters just because it COULD be used wrong. Let code analyzers like FxCop have rules to catch bad design, but dont take a powerful feature out of my hand just because some people might use it wrong. As long as the documentation supports me in learning this, I will learn how to use this judiciously.

    Word is here today. Also there are some DCOM programs out there that have long chunky method calls. Used judiciously this could be a powerful feature.

    Now, if this isnt enough to persaude you, how about giving us the capability to consume methods with optional parameters, but not the ability to create them?
  • Anonymous
    June 23, 2004
    Cleve: I never said that that was the reason why we left it out. I just pointed to potential problems.

    With your logic then there's no reason not to add anything to the language. How do you make any decision on a feature then. You could always say "it makes things nicer for some people". We need to decide on a lot of things.

    How would you decide if a feature should be added to the language or not?
  • Anonymous
    June 24, 2004
    How about Read Mode versus Write Mode... Word adds little niceties when you're reading, why not my code editor.

    XML comments could be formatted nicely; Method, variable and class names could be turned into hyperlinks could take you to the definition/declaration of the method, variable or class.

    Still not sure if I like it, but I thought I'd put it out there. By the way, this wasn't my idea directly, but an amalgamation of ideas I found online.

    Orion Adrian
  • Anonymous
    June 24, 2004
    Orion: We're actively looking into the things you've described. Nice formatting of comments and also hyperlinked based navigation :-)
  • Anonymous
    June 24, 2004
    Wesner: I'm currently reading "The Synthesizer Generator" http://portal.acm.org/citation.cfm?id=62021&dl=ACM&coll=portal

    It prsents a system for diong the same things you listed on your page. What's interesting is that these ideas have been around for decades, but they still haven't taken off. For some reason people still want the flexibility of text input.

    Weird hunh.

    Good read btw.
  • Anonymous
    June 26, 2004
    I just spotted that Mike Scott and I share the same wish about enums :-)
    http://weblogs.asp.net/fmarguerie/archive/2004/06/24/164623.aspx
  • Anonymous
    June 29, 2004
    The return of the '<> ""' when checking for null database values..the dbnull thing bugs me, and goes against what I would intuitively thing to use (coming from a VB background)
  • Anonymous
    June 29, 2004
    Kevin: Nullable types should help you in the respect. Instead of getting a DbNull back you should get something back like a Nullable<int> (aka an "int?"). You can then test that nullable type againt "null"