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

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 (53)
  1. 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


    public int Length {

    get {

    return this == null ? 0 : InternalLength();




    string a = null;

    Console.WriteLine( a.Length );

    will print 0 and will not raise an exception

  2. Ron says:

    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)

  3. Eric says:

    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.

  4. damien morton says:

    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" 🙂

  5. Kavan says:

    I don’t see optional parameters and named indexers. Is this something you already have in C# 2.0? If so, great!

  6. I still want Edit and Continue and this time I want to expand my requests for Windows Installer to make it so that you can program against the Windows Installer framework in C# and script every part of the Windows Installer using C# so that I can write scripts directly and have them execute in Windows Installer that allows me to manipulate every part of windows installer as if it were dialogs in a winforms application.

    Windows Installer is baberic and broken… time to release a .net version of it that is completely programmable and fixes all of the bugs in it (see other blogs for the many many many issues). (and native to the CLR)

  7. Orion Adrian says:

    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.


    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

  8. Eric: We’ve added automatic enum preselection in C# 2005. Any other VB’isms you want?

  9. Kavan: Optional parameters and named parameters are part of "VB = C#"

  10. Orion: Is int* a list, a collection, or a set?

    Are there built in operations for maps?

  11. OMer: Thanks! I’ll add those tonight.

  12. Andy says:

    "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.

  13. Daniel O'Connell says:

    I’ve said it before, I’ve said it again: Better casting operators! The ( ) sucks, as is the only decent casting operation in the language.

    WRT raising events without a null check…has the team considered the raise event accessor? It’d be pretty easy to generate a raise accessor that did the null check for you, thread safely would still require an override, but it would get rid of the null issue. I am still kind of curious why C# never bothered with raise.

    Interface delegation mapping. Being able to map an interface to a field or property and let the compiler generate wrapper calls that calls the interfaces methods on that field or property. I’m not sure if that is covered under more flexible interface implementation or if you mean the VB like interface implementation.

    Exception filtering and user filtered catch handlers are the same things, aren’t they? Anyway, the filters are usually used for logging purpose because the exception information is different in the filter and in the catch handler. So I see alot of people use them to write their own style minidumps or logs. Personally I’d prefer to see an additional trycatchfinally clause called log. I wrote an implementation of log(in mono) using a filtered catch taht always returns false. The basic format was

    try BLOCK catch_statements optional_log_statement finally_statement














    for example, where log is called in the context of a filter but is clearly for the purposes of logging instead of an abuse of another facility.

    Normal filtering is valuable if you rely on underlying exception data. It would more likely make code easier to maintain by having seperate catch clauses for a specific type of exception based on member values, however its not as vital for that, IMHO, as you could pretty easily refactor it into several methods and end up with simpler code over all.

  14. 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.

  15. Kavan says:

    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.

  16. Kavan says:

    Shouldn’t copy/paste. I mean optional parameters and named indexers.

  17. Cleve Littlefield says:

    I disagree with the guys who want to kill Tag. I know this is not your area Cyrus. But personally I think the Tag property provides versatility in quick one-off scenarios where you are unwilling to create a whole type just to tag some data along for the ride. I agree if you are making havey use of this property something is wrong, but I think it should be added everywhere it doesnt currently exist.

    I also like Orions idea of propagating instance operations to arrays of instances. Although I can imagine that it might be harder to read and if not used judiciously might be a performance impact.

  18. 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?

  19. 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.

  20. Daniel: Note. My comment was referring to null checks on events.

  21. I read an interesting comment in response to one of the Blogs made by Paul Vick – http://www.panopticoncentral.net/archive/2004/05/28/1085.aspx. It was by a guy named Eric Mutta and i’ll just copy and paste it in (not sure if i can put html in these comments).

    "I would pay millions for a smart editor that could recognise common coding patterns then suggest some functionality in the framework that implements the needed functionality (a good example is using a loop to copy array elements instead of just calling System.Array.Copy)."

    It was a discussion on dealing with learning the framework for the first time when migrating from a non .net language. I know that VS 2005 has the beginnings of this with the balloon tip exception debugging and stuff, but it got me thinking.

    General coding advice could be quite useful. In a way, it’s a performance thing, but i think we all know just how easy it is to get lost in the framework and discovering exactly what exactly is in there – i’m sure we’ve all reinvented the wheel many times, written a slick peice of code to discover that it could be done by calling something in one line of code that exists in the framework already.

    In a way i’m thinking this is a design time fxcop that does more then look at coding practices, but looks for common coding fragments and maps them to framework calls.

    Thought i’d throw it in just in case.

  22. Daniel O'Connell says:

    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):



    if (DelegateField != null)



    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?

  23. 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

  24. re: code helper

    Cyrus: i never said it would be easy. the more i think about how it could be implemented, the more i get scared at the amount of work it would involve! And yes, i have a dreaded image of the paperclip appearing and giving some advice, which is bad. Obviously it would have to be switch off-able, as i imagine it would degrade designtime performance (much like the dynamic help does now)…

    I don’t know about you, but that just made my brain fart…this is really just an extenstion to the classic dynamic help isn’t it? dynamic help combined with balloon tips, combined with a hell of a lot better documentation…perhaps plugging in all the ‘best practices’ guides that have been written…. eh, i’m waffling on a bit now, and i really wish i could take the credit for thinking of it (never mind if it’s really hard to write and won’t appear for another 10 years!).

    The other danger that could come into play is that suggested replacements would have to be carefully selected, or the end result will be very average code that is not optimised at all.

    Oh well.

  25. Kavan says:

    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.

  26. 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.

  27. Orion Adrian says:

    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

  28. 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.

  29. Orion Adrian says:

    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

  30. 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

  31. Orion Adrian says:

    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

  32. Cleve Littlefield says:

    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.

  33. 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.

  34. 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 🙂

  35. Frans Bouma says:

    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. 🙂

  36. 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

  37. Ian Horwill says:

    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

  38. David Levine says:


    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.

  39. David: It’s in the list. 🙂

    Under the things we would work with other teams with.

  40. Mike Scott says:

    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):


    Colour = ( red, green ) ;

    … somewhere else in a code file far far away…


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

    Now, if I modify the declaration of Colour:


    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:


    MyChoices : array[ Colour ] of MyDelegate ;

    in the code I can write:


    aDelegate : MyDelegate ;


    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).

  41. Eric says:

    "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).

  42. Luke Stevens says:

    Whatever happened with explicitly boxed value types? I mean like int* where you hold a reference to a boxed int, rather than an unboxed one or a weakly-typed object reference. I understand that Nullable provides many of the same benefits, but there are still cases where this would be useful, like being able to say "int* foo = bar as int" or something.

    And I’ll add to the list Doug’s idea about letting references have multiple types: being able to say something like "{IConvertible, IDisposable} item" where item is then a single reference to a single object that implements both interfaces.

  43. Diego Mijelshon says:

    I have a real example of this in one of my class libraries:



    someMethodInfo.Invoke(someObject, null);


    catch (TargetInvocationException ex)


    if (ex.InnerException is MyActualException)


    //Do something







    It would be nicer to do something like this:



    someMethodInfo.Invoke(someObject, null);


    catch (TargetInvocationException ex where ex.InnerException is MyActualException)


    //Do something


  44. Wesner Moise says:

    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.




    I am posting it here because you may not be looking at your earlier posts.

  45. Cleve Littlefield says:

    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?

  46. 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?

  47. Orion Adrian says:

    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

  48. Orion: We’re actively looking into the things you’ve described. Nice formatting of comments and also hyperlinked based navigation 🙂

  49. 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.

  50. Fabrice says:

    I just spotted that Mike Scott and I share the same wish about enums 🙂


  51. kevin says:

    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)

  52. 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"

Comments are closed.

Skip to main content