Product feedback and language design

I got an email today with a suggestion for a C# language enhancement, and I pointed the person to the MSDN Feedback Center, which is the best way to give the language team usable feedback. If a lot of people want something, it helps aggregate the feedback into something more definitive.

Note that popularity doesn't ensure implementation, for reasons that I've covered in the past.

Comments (11)

  1. I’ve tried to go this route in the past but found that what usually happens is that I get quick feedback of the "this is a good idea, we’ll look into it" variety, and several months later it’s resolved as "By Design" with no further comment.

    I posted (and voted and commented on) several issues about nullable types, and this was the outcome every time. The issues I posted are sufficiently serious, IMHO, that I’d actually rather C# hadn’t introduced nullable types *at all* because I could do a better job at writing my own Nullable<T> class than what the framework did. Furthermore, while there are quite a few places where syntactic sugar would be useful in dealing with nullable types, *none of these* actually made it into the language.

    If the people who looked at my feedback requests went through a process similar to what you describe in your linked post in order to decide to reject the suggestions, surely it would be possible to post some of the *reasons* why the ideas were rejected? A resolution of "By design" with no comment sounds a lot more like "actually we decided we couldn’t be bothered to look into this after all", which is disingenuous after originally claiming it was a good idea and promising to investigate.

    This is why I tend to post suggestions, comments and complaints in blogs rather than in the Feedback Center – because blog comments tend to get better responses. See for example Cyrus’s recent post "Too Many Options!" on code-generation behavior for a particularly spectacular example of responsiveness which contrasts sharply with my experience in the Feedback Center.

    FWIW, some examples of the problems with nullable types in C# 2.0:

    What I could solve in an alternative implementation:

    (object) (int?) null == null; // evaluates to false!

    (note that although I *could* solve this, it could be solved *better* with language help – the only solution I could provide would be to use a class instead of a struct, wheras a language- or framework-supported solution could support this even *with* a struct)

    Things I couldn’t solve without language help:

    int? i = (int?) (object) 1; // InvalidCastException

    int i = (int) (object) (int?) 1; // and again

    int? i = condition ? 1 : null; // compiler error

    DateTime? dt; dt.ToShortDateString(); // compiler error, need to do .Value first

    Things the current solution achieves that I couldn’t:

    Pretty much nothing except for "int?" as an alternative syntax for N<int>, which isn’t a terribly huge win in my book…

  2. Angel says:

    Hi there. I just wanted to say that I have been learning C# over the past couple of months and think it’s great. There are things in everything that we would change for our own needs … but we have the flexibility to write things for ourselves. Kudos to you and your team for an excellent product.

  3. ericgu says:


    I know the intention of the system was to be able to provide something more than just "by design". Alas, since I’m no longer the C# community guy, I don’t directly own ths, but I will forward your concerns to the people who own the process now.

  4. TAG says:


    I understand your pain. Yep Nullable in C#2.0 are real disaster.

    Instead of simply adding a ==null , !=null operators – Microsoft has introduced new type with a bunch of limitations like a :

    a) T is not sub-class of T? 🙁

    b) T?.Value copy all data before calling any methods 🙁

    Point? p = new Point();

    Console.WriteLine(p.Value.X); <– Combined with no inlining support in CLR – this will copy entire struct data several times 🙁

    c) There is no way to copy data back in T?.Value property (probably done to trigger error for users who unaware of b) )-:

    d) If you wish to support some methods taking any T? or T – you most-likely have to code both versions 🙁

    e) T? does not implement any interface T implement – thus T? is semi-useless for generics (yep, I’m aware on hacks )-:

    I’m still unable to get good answers on several of my questions like an (under my old nickname AT – Community Server fell that it’s too short)

    Possibly I’m missing something – but I was unable to find a document / webpage detailing suggestions/requirements/tradeoffs used while designing Nullable<T>. {Hint: Anybody can share a link ? }

    This make me feel I was able to implement this feature somethat better. But most likely I’m wrong – as I’ve missed something extemely important why this design were used.

    IMHO – the best thing that developers can do – is simply ignore structs / nullable in current C# iteration. Thouse features must be used only if you know for sure that you can not live without them.

  5. I posted my feature request at:

    I figure it can’t hurt to post it there since I already pestered Eric about it in emails.

    I’m wondering if I should post it to the forum Eric recently mentioned and the newsgroups.

  6. Luca Bolognese says:

    To Stuart regarding his comment on the C# team not posting the reasons for fixing a suggestion as ‘by design’. I consider that an incredibly bad behavior and if it ever happened for us, I would be very disappointed. We really spend time looking into suggestions and replying to them. Sometime our reply can be a bit terse, because of the volume of questions, but we should always justify our choices.

    I went through our database and found this single post from you, which has been resolved as ‘by design’, with a comment explaining the reasoning:

    Please point me to the ‘by design’ posts closed with no text by the C# team and we’ll certainly investigate them.



  7. Luca Bolognese says:

    Hey TAG,

    the status of this is ‘Under Review’. It has not been closed as ‘by design’ with no comment. Peter pointed you to his blog, you disagreed with him, you reopened it and now it is his turn to reply. It seems that everything is OK on this one.


  8. Here’s the one I was thinking of.

    Note that although there *was* a comment with the resolution as "by design", it certainly didn’t explain why the issue had been resolved. In fact, it specifically said that "we’re actively exploring this kind of feature at the moment" – ie, we *haven’t* yet decided that we aren’t going to implement it. IMO, it shouldn’t even have been marked resolved if you were still exploring the issue.

    There’s still been no followup to indicate the results of that exploration. There was some speculation of why it *might* (in the then future) turn out to be too hard to do, but no confirmation of which, if any, of those things turned out to apply.

    (and FWIW, I wasn’t too happy about the comment in the other issue, either, because it entirely missed the point… the current boxing behavior of nullable types *is* confusing, to the point that I’ve already seen numerous blogs explaining how people discovered this confusing behavior, so it’s pointless to claim that changing that behavior would be confusing. And default(int?) as a workaround is longer to type and less clear than (int?)null)

  9. TAG says:


    Take a look on dates. 2005-01-21 and no reply.

    Compare with my timing:

    January 19, 2005 7:53 PM by peterhal and answered January 19, 2005 10:52 PM !

    Peter did not bother to answer on comments in his blog :-((

  10. Luca Bolognese says:

    Hi Tag,

    we are all working very hard on closing down Whidbey. Our tournaround time may be a bit slow in this period. Peter in particular is working on two last minute changes. He didn’t close the bug with no comment.


Skip to main content