What features would you like in the next version of Visual C#?

Article
06/20/2004

I ask this question because C# 2005 is getting more and more solidified as we approach the release date. Adding new features at this point involves determing how much benefit the user will get out of it versus the cost to design, implement and test that new feature. As we get closer to ship date the feature has to get more and more compelling with less and less cost. This is an example of "raising the bar". If we don't keep that bar high then we'll introduce something that we don't have enough time to get to the quality that people want and we run the risk of destabalizing the product.

This also means that as time goes on features that are currently in the product might get cut. Even if they provide high user value, if there isn't enough time for a dev to implement it it will be cut. If the dev can (or has) implemented it, but there isn't enough time to test it, it will get cut. I've had this happen with three features that I added in my spare time. Anson and Kevin both experienced this as well. It's kind of depressing, but with a limit on how many resources you have it just happens. I'd like to talk about those features to get some feedback on how useful people find them, but I'll have to run that by Jay first to know if that's ok.

However, when we cut something we don't say "we're not going to do that ever," instead we say "we're going to postpone work on that and come back to look at it later." Then, when we add that to the list of things we want to do for the next version. When we get around to planning that version we prioritize those features, try to estimate how long it will take to add them and then we pick a subset of all the things we have that we feel will provide the best user benefit.

Features that are chosen then have a very high chance of staying in the product. Features added later have a much higher chance of getting cut because they add pressure on everybody later in the game when, most likely, all schedules are packed. Cutting current features to make time for the new features is a tough sell because of all the time already spent and also the risk of destabalizing when you remove that code. All in all it's a tougher thing to do. Note: this is just a simplistic view of things from a dev's perspective. Anson and Jay would probably be able to explain this a lot better from a PM and Lead's perspective.

So, if you have features that you really want in the next version of the product, now is the time to ask for it. We'll add those to the list and if they're good then they'll get done. Note: feel free to make suggestions about any part of the products, but know that we (well me specifically) are focussed on the code editor and compiler for C#. We're very interested in everything else (like WinForms or the base class libraries), but other teams take care of those so they'd understand it better than we might. However, we'd send all of this information to the teams appropriate to handle it.

I might add that detail would be appreciated with the responses. Rather than just "add emacs support" explain in depth what aspects of emacs you really like and how they would benefit you substantially. For example, is it just the keybindings, is it something about the interaction model, etc.? You also don't have to talk about humongous feature additions like "vs should add refactoring support", you can instead talk about little things that drive you nuts in VS7/7.1. Like "i hate it when I'm typing and 'foo' happens and suddenly I have to stop what I'm doing to fix it," or "why can't the C# editor help me when I'm doing 'bar'? I waste so much time doing it over and over again". These can also include things related to exposing libraries for you to interface with as opposed to just features in VS that you interact with. If you wanted programmatic access, what would you like to see exposed?

Maybe I'll be able to tell you: "Hey!! We added that in C# 2005." Or maybe we'll actually realize that what you're talking about is a bug that we should fix before 2005 ships. But if it isn't one of those then we will add it to the list of features to consider for the next version and you will have a chance to get what you want.

I wish that we had a better system for doing this rather than asking every so often on a blog. A public suggestion system would be ideal. Preferably with two way communication so that people would know that they were getting heard and that these features were being considered. But until we have that, I'll have to do this the hard way.

If you think C# is perfect, then feel free to keep quiet. However, I certainly think that it could be improved immensely and I want to try to do it in a way that benefits all of you. I'd also like it so that in the future we had a much faster ship cycle. That way if you wanted a feature we'd be able to get it to you in 3-6 months. Currently we have a cycle that is multi-year. So we ship a product that is much improved across the board. But if we don't have the feature you want then you're not going to be getting it for another few years. Note: things like ship cycles are also things that you can request. If you want us shipping faster, let us know. Later on I'll try to bring up the issues surrounding that. But if you do find that compelling, let us know!

Let me explain. No, there is too much. Let me sum up: let us know!

Comments

Anonymous
June 19, 2004
The comment has been removed
Anonymous
June 19, 2004
The comment has been removed
Anonymous
June 19, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
Not C# specific but DevStudio related:

Add Some new view to Solution explorer:

We now have 2 view

1) Normal with all file in the project arranged in a tree.

2) Hidden files are shown.

I would like to filter the first one by only the openened ones. ( because, lets be blunt. the current tab view for opened files blows!)

Ex (number denotes level in the tree):

1- Application
2- Folder1
3- File1.cs
3- File2.cs
3- File3.cs
2- Folder2
3- File4.cs

If only File2.cs is opened i would only see:

1- Application
2- Folder1
3- File2.cs
Anonymous
June 20, 2004
Intellisense to show a class has an indexer [...], show it at the top of the list of methods or something similar.

* Some indication that a type supports IDisposable -> create a smart tag popup for the class to provide the option of moving that class into a using block.

* Create a constructor in a child class that calls the base class setting up all the parents parameters.

* Copy a constructor. If I want to copy a constructor to add a parameter, I have to manually copy the definition, put all the parameters in the this(name, phone, email) etc. This could be easily automated leaving me to do the job I'm trying to do - add a new parameter as an overload.

* At the moment there is the option to Generate Method Stub. I'd like to see Generate Class Stub. This would allow a class to be prototyped, and then the class and it's methods generated from the usage.

* I'd like the prop and propg templates to generate to specific regions so that they can be grouped together. I usually put private variables above the constructor and properties below.

Cheers,

Duncan
Anonymous
June 20, 2004
One more...

* For regular expressions to be treated as an operator as the are in JavaScript and Perl.

e.g.
if (/w{3,6}-d+)/) {
// do something
}

This would get rid of a lot of the unnecessary escaping of characters that goes on now.

Cheers again,

Duncan
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
In no particular order... and maybe not for C# 2.0...

* Covariance and contravariance of paramater and return types in interfaces and delegates. This is a purity issue.

* A well organised set of generic collection classes

* reference typed variables/paramaters/returntypes declarable as not-null

* implement more of c-omega and shamelessly steal from the nice langauge
- tuples
- functions in module scope

* precondition and postcondition functions delcared in interfaces

* enforcement of rules allowing extensibility - "a sealed class cannot be used as paramater or return type of a public method - use an interface instead"
Anonymous
June 20, 2004
Damien: Co/contravariance is supported on delgates now. Unfortunately not interface (yet). If I get my way we'll have that though.

We have generic collections for 2005. Is there something you don't like about them? If so, i'll get that feedback to the designers

Can't help you on the non-null part :(

Tuples would be great. I was going to rant on that later. We'll definitely be looking into that for C#

Functions in module scope? Can you give an example of when that's nice?

Pre/Post conditions. Yep: although I'd like a more general architecture.

Enforcment of rules: FxCop will do that for you.
Anonymous
June 20, 2004
David:

I like the different color scheme idea. I'll talk about that in a later post and how to address it in a more general way

Autogeneration of tests: Included in the new VS Team System

Solution into a makefile: In 2k5 a solution is automatically an MSBuild makefile

I need more feedback on how to make MSI generation better.

C# Specific:
Can you give me an example of where/how the exception filtering thing is useful?

I'll check and see if we are exposing those profiling/callback APIs through maanged code

Your tools suggestions are excellent. Thanks!
Anonymous
June 20, 2004
James: Tell me how you really feel :-)

What is this Edit and Continue. It sound familiar ;-)
Anonymous
June 20, 2004
Frankie Fresh: No suggestions of your own?
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
Jim: What would you do with the managed API? (Seriously, I want to know :-) )

See Jay's blogs.msdn.com/jaybaz_ms page on how he gets around the null check with events. But I do agree that it's annoying for the implementor

Virtual by default: You can get this with an FxCop rule now.

We're always trying to balance simplicity of work with density of syntax. is "new int[] {1,2,3}" too much clutter for you? If so, are there are areas that you would like simplified?

Enum: Sounds good. At least for enums that don't have the 'FlagsAttribute' set. Although it seems like you could write your own static method for that.
Anonymous
June 20, 2004

Edit and continue.
2) Covariant return types. I'd rather type this:

public TimeSpan MyMethod() {}
public DateTime MyMethod() {}

...than this:

public void MyMethod( out TimeSpan ret ) {}
public void MyMethod( out DateTime ret ) {}

3) Bundle an xbox with every copy of VS.net.

Anonymous
June 20, 2004
david: I'm confused. If the files aren't showing in the solution explorer how would you open them?

Also, please be specific in how you don't like the tab view for files. Just "it blows" won't get anything fixed. But if you point to specific ways that it's unusable, or show scenarios where it falls down, then it c an be addressed
Anonymous
June 20, 2004
Duncan: Agreed. We shoudl show indexers, casts, possibly implemented interfaces. There are a lot of things we are thinking about for how to help you out in this regard. I'm pretty certain that we're going to be addressing all of them.

DaigoH had the exact same idea about IDisposable. I like it. Another option is a warning if you get a disposable object but dont' dispose it.

I see Generate Method Stub (yaaay, my feature) evolving into a general purpose automatic generation tool. We wanted to get the most important stuff in since it was feature added so late in the game, but I think we'll be focussing on it highly next time.

You can change the prop template yourself. Is this something you don't want to do?
Anonymous
June 20, 2004
Duncan: I'm going to write a post later about embedded regexps. Neil and I were talking about this earlier and it's something I've discussed a lot with my team.
Anonymous
June 20, 2004
Cleve: What interface would you like to see the refactoring API expose?

What would C# macros get you over running things through a C preprocessor? What power are you missing today that you think macros will get you?

I beleive String.IsEmptyOrNull will do what you want.

Why do you want VB/C# to be the same? If they were the same would there be any reason to pick one over the other?

Interesting ideas about the Dynamic Mock object support. I'll talk to jay about that.

I added the feature to 2005 where we will add the usings for you for types that you use.

If you add your usings under the namespace then we'll follow that pattern and generate them there as well.

Talk to reasearch about getting us those complexity tools :-)
Anonymous
June 20, 2004
Len: We were thinking that an XBox2 would be better. But given yoru suggestion I think we'll curb it back to an XBox1
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
AT: I'll send that off to the UE guys so they know that that's what you'd like to see.
Anonymous
June 20, 2004
Duncan:

---
* For regular expressions to be treated as an operator as the are in JavaScript and Perl.

e.g.
if (/w{3,6}-d+)/) {
// do something
}

This would get rid of a lot of the unnecessary escaping of characters that goes on now.
---

Did you know about @ strings? If you type @ before a string, then the only thing you need to escape in the string is the quote character. Hopefullt that will help you out.
Anonymous
June 20, 2004
Enforcment of rules: FxCop will do that for you.
Anonymous
June 20, 2004
Edit and Continue
Anonymous
June 20, 2004
Priorities. I think the features which hold promise for shorter development times would be the ideal top priority. Once these features are pushed out the door, the job to further build up DevStudio will be hopefully shorter as well.

This is common sense, but I would have expected some of the suggestions to be common sense as well, even if they lacked the specific detail as to what is bugging the user.
Anonymous
June 20, 2004
Stephen: What features do you believe would hold the promise for shorter development time?
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
Hi Cyrus,

I do know about the @ with strings, you're still required even then to escape the double quotes. I've done a lot of Perl and JavaScript and being able to just write the regex without worrying about escaping is far more natural and expressive to me. Also, if you look take a look at http://www.perldoc.com/perl5.6/pod/perlfaq6.html#How-can-I-hope-to-use-regular-expressions-without-creating-illegible-and-unmaintainable-code-
you can see how comments could potentially be embedded making the regex self documentating. The biggest weakeness for me with regexes is often working out what
they do again after you've written them :)

So for me that's the regex with as few character escapes as possible.
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
How about making operators virtual and allowing them on interfaces?
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
IDE
* The IDE seems to have two modes: debugging and non-debugging. There's one guy on our team who likes this, but the rest of us don't like having to configure toolbars, panes, etc twice (and never quite getting them exactly the same in both modes). An easy way to save and load IDE preferences might cure this, and would make upgrading to a new machine easier too.
* Better support for multiple monitors. Most developers at our company have dual 19" screens, for a desktop of 2560×1024. My machine has three 21" screens, for a desktop of 4800×1200. In MDI mode, the IDE insists on opening windows to nearly span my entire desktop, so I have to resize everything after I open it. How about a sanity check of 1200 pixels wide for new MDI windows? In tabbed mode, I want two side-by-side panes per monitor, or some way of making panes snap to an immobile grid. Instead, the panes keep shifting around, and need to be tweaked to keep them in place. Also, the IDE sometimes gets in a funky mode where the splitters between panes can't be moved.

FORMS DESIGNER
* Get rid of (or let me turn off) accidental double-clicking in the designer causing the addition of an event handler. It seems like every other time I open a form, Visual Studio thinks I double-clicked, and I get an unwanted form1_Load or panel1_Paint event handler.

SOLUTION EXPLORER PANE
* Let Alt-M, Alt-O collapse the Solution Explorer pane's treeview. We've got 75 projects in our solution now, and manually collapsing all the projects in Solution Explorer is a pain.

EDITOR - #REGION
* Standardized regions would be nice - #region Data, #region Properties, #region Event handlers, or something like that
* Regions should be automatically collapsed when I open a code window. Either that, or save the expanded/collapsed state of the regions.
* The state of regions being expanded/collapsed should be part of the view, not the document. For example: I open two windows for a document, find the method I want to see in the first window, then go to the other window and automatically hit ALT-M. ALT-O, which makes me lose the view of the method in the first window. Aaargh!

EDIT AND CONTINUE
* It's a big-ticket item, but it would help. On my old machine (2GHz, 500MB), a low-level code change would take over 10 minutes to compile. On my new machine (3GHz, 1GB), it's only 1 minute, but edit-and-continue would still help, especially when working on custom controls where you really need to see the visual results of tweaking.
* Not really edit-and-continue, but when changing a custom control, the designer often won't show the changes, even afer a full recompile. One cure is to close and re-open the solution. Another is to make sure that all designers are closed before compiling, but that's easy to forget.
Anonymous
June 20, 2004
I want haikus to pop up randomly to help me think. They could either be off-topic in order to inspire me or they could be related to what I was typing at the moment. Like if I'm writing a for-loop and I don't make the end-condition correct, it could go:

infinite spiral
your code descends to madness
change value of i

Or maybe it could serve an entirely different purpose. Maybe it could figure out when I'm writing a haiku (similar to what you're proposing for regexps <a href="http://blogs.msdn.com/cyrusn/archive/2004/06/20/160788.aspx)">here</a>) and offer up domain specific information that would change as I type. What do you think?
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
Aleksei: Not sure what you're discussing with the XML/CSS thing. What would you like?

Luke and i were talking about this for anonymous delegate syntax:

optional_parameter_list block.

so you could write:

public int Count {
get {
int count = 0;
this.Iterate({ count++; });
return count;
}
}

instead of:

this.Iterate(delegate { count++; });

I find the delegate keyword very heavyweight. Oh well...

And yes you can run the block on another thread.
Anonymous
June 20, 2004
Doug: Would :

where T : ISerializable

be good enough?
Anonymous
June 20, 2004
XML/CSS would provide a way of syntax colouring of C# code. But it's a thought spoken aloud rather than a wishlist item.

On delegates.
Those parenthesis look strange. In ruby one writes

range(1,1e50).Iterate( 2 )
{
x| sum += x
}

instead of

range(1,1e50).Iterate( 2, delegate(x)
{
sum += x
});
Anonymous
June 20, 2004
Cyrus,
No, unfortunately it isn't. Ooodles of types are serializable but not ISerializable (examples: System.String, System.Int32, the vast majority of my serializable user defined types). I need to constain based on the serializable bit in the metadata, so that I know if I can actually expect to be able to serialize something. ISerializable is only if a type needs fine control over its serialization.

Scenarios:
1) I have an IEntity interface for my business objects that returns a key that can be used to retrieve them. It's great and it enables tons of stuff in my data layer and elsewhere. IEntity<K> will be even better, but only serializable types can be keys, because I have to know that I can persist them to disk or send them over the wire. The most common key types are Int32, Guid, Int64, and String, none of which is ISerializable.

2) It seems to me we need this constraint in order to mark generic types with fields typed as a type parameter as serializable:

[Serializable]
class Example<T> {
private T _someThing;

...
}

doesn't really seem like it should work without where T : serializable or marking _someThing as [NonSerialized]

What do you think? I think this is a critical feature for generics, but I haven't seen it addressed anywhere, so I don't know if someone has this on their radar or if I am just missing something or what.
Anonymous
June 20, 2004
Aleksei: The parenthesis probably look strange because you're used to Ruby. I find the idea of a block just floating around not as an argument to be extremely disturbing. That said, I also find the use of the word "delegate" to be way to heavyweight.

I'd prefer something like:

range(1, 10).Iterate(2, (int x) { sum+= x; });

I like that syntax because it's very analogous to how you write out an actual method like:

Add(int x) {
sum += x;
}

Except that you haven' written down 'Add'. The use of would be to help disambiguate the parameter list from our horrid cast syntax.
Anonymous
June 20, 2004
Doug: I see. I can give you a suggestion but I'm not sure if you'll like it.

public class Entity<K> {
static Entity {
if (typeof(K).GetCustomAttributes(typeof(SerializableAttribute)).Length == 0 && ! typeof(K).InheritsFrom(typeof(ISerializable)) {
throw new YourException("You can only instantiate with a type variable that is ISerializable or has the SerializableAttribute on it");
}
}
}

Yech... but it kinda works.
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
Aleksei: Ah, I see. That's interesting.

Can you give me an example of what you mean by "create my own class of classes" or an example of a "virtual class method". How would that work, what would the benefit be? What would you be able to do with that that you currently can't do with C#
Anonymous
June 20, 2004
Exactly. Yech. I agree it kind of works, that's my current plan, and backed up by an FxCop rule it will be a decent workaround, but I think it is sufficient motivation for adding a serializability constraint. Especially since the syntax extension is minimal.

Drawback to my suggestion:
Serializability of A does not guarantee serializability of B, when B : A. Hence, even the constraint is not an iron clad guarantee of serializability (unless combined with a value-type constraint, I guess). I will ponder the implications of this.
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
Haha, oh no, not this again! :) See the thread about what belongs in an interface for my answer to that question.
Anonymous
June 20, 2004
Oh, and in regards to this:

""Functions in module scope
You can use static methods to simulate, but sometimes its just more aesthetically pleasing not to have to prefix with a "namespace".
Examples: Map, Reduce, Filter... so much nicer than Functional.Map, Functional.Reduce, Functional.Filter
not everything is an object or a class. "

Why would Map/Reduce/Filter be in the global interface and not on the list interface?"

I seem to remember a suggestion for extending using to allow:

using System.Math; // name a static class instead of a namespace, and the methods of that class can be used directly

Possibly a good idea, since I don't know about moving those methods themselves to the module level, especially in the System namespace, just so that they can be undecorated. Especially since people are so likely to want to reuse those names for other things.
Anonymous
June 20, 2004
Geoff: C# also has unmanaged code in it. Would you merge that into VB as well? I don't see that being something VB would like.

I see the 3 languages targeting different types of developers with different needs. The features that each provide were decided by taking their respective users and deciding what they would find most useful for the next version. Note: E&C was proposed to C# users and the feedback we got what that while people wanted E&C they said they wanted refactoring more. VB did the same but found that its users wanted E&C.

The languages are also not the same. Things like iterators and anonymous delegates and nullable types are areas where C# moved forward based on the type of work that our customers do, whereas I think that VB looked at them and decided that it's customers wouldn't benefit from it in the same way.

I can't talk about our internal code or how much is shared.

However, at no time did we ever say "no one wants E&C". Instead we asked ourselves "given the time and number of developers we have, what can accomplish in the whidbey timeframe?"

There's a lot more I could tak about, but I'd like to hear your feedback on this
Anonymous
June 20, 2004
Doug, I like the idea of "using" a class and getting access to the statics in it. Definitely worth looking into.
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
If I understoond Your question, I cannot give an example.

But on the other hand it's possible to emulate virtual instance methods through reflection. It's what do I now to emulate virtual class methods. I simply declare static methods and obtain their infos through reflection. Performance issue.

Why does C# provide virtual instance methods while the same behaviour could be achieved without new syntax rules?

What about restricting methods taking Types as arguments to receive only a limited set of types?
Anonymous
June 20, 2004
Sorry Aleksei, I'm just not getting it :(

Can someone help me understand the issue?

C# already has virtual instance methods. But I thought I say you mentioning virtual static methods above. If that was the case then I couldn't figure out what that would even mean and I was hoping for an example to show how it would be useful.
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
...And one more reason.
As I see in hierarhy tree System.Type is an abstract class. Is not it a class for classes?
Developers of the .NET needed a class of classes for some purpose ;) Why others will not need somethign like this?
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
I agree with Geoff and Cleve that VB.NET and C# capabilities should be identical. It makes no sense to me to create features (for either language), and not roll that them into both languages. The job of converting from one language to the other should be just a click, not a human-programmer task.

As to the "3 different types of developers with different needs", it would be great if Microsoft were to think of that as 3 different views into the same development environment, instead of three different development environments in the same IDE. The 3 types of developers model is at best theoretical. Many programmers do not fit well in such a model. The model's just an invention, not a reality.
Anonymous
June 20, 2004
+1 on the VB.Net/C# differences. I also want the My namespace. Perfect for tossing up quick prototypes, but I really like my semi-colons as well. I don't see why I can't benefit from this feature in C#?

I agree with BillT. I am "a different type of developer" depending on which time of the day you ask me.
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 20, 2004
Another +1 for VB.NET/C# having the same functionality when it doesn't compromise the language. At least properly support optional parameters and named indexers/properties with parameters. I want C# users to be able to consume VB.NET dlls without the trouble they get now because of lack of support for this. You don't have to add support to create this functionality in C#, just add support to consume it. At least properly consume CLS-compliant code, that's all I'm asking.
Anonymous
June 20, 2004
The comment has been removed
Anonymous
June 21, 2004
Am I off base with the whole "async"/"sync" language extensions? I've noticed no one posted a comment at all.
Anonymous
June 21, 2004
"What would you do with the managed API? (Seriously, I want to know :-) )"

Specifically, write a code style enforcer. FXCop is great, but it works on MSIL, not source code. It would be sweet to be able to parse C# files into a CodeDom tree and run check on that. I can think of other applications too (testing the output of a code generator, for example).

"Virtual by default: You can get this with an FxCop rule now."

Yeah, but first-class support would be nicer. Classes aren't sealed by default, so why should methods be?

"We're always trying to balance simplicity of work with density of syntax. is "new int[] {1,2,3}" too much clutter for you?"

It just seems weird that I can do:

int[] numbers = {1,2,3};

but I can't use the same syntax for inline instantiation.

Jim
Anonymous
June 21, 2004

Integrate more C-Omega stuff. (Like, ?, +, *, !) and inline XML and inline XPath
2) Declarative restrictions that automatically throw exceptions for me. (See Eiffel)
e.g. If a number has to be between 1 and 100 (say an index), I should be able to say

object this[ int index ]
[ check( test, exceptionConstructor() ) ]
[ check( test, exceptionConstructor() ) ]
{

}

This could eventually be expanded to something truly declarative like:
index inrange 0 to N
index nonnegative

which could give warnings or errors when the invariants aren't met.

I miss const :(

Orion Adrian

Anonymous
June 21, 2004
I'd like to see the new VS.NET Team Edition support the provider model for source control and unit testing.

Thus I could switch the unit testing built in with NUnit for example. I realize that it might require tweaks to NUnit, but in principle , NUnit (or mbUnit) would be a provider for unit tests.
Anonymous
June 21, 2004
Generic properties where you can specify the returned type. It would be nice if you could do the same thing as with generic methods.

class MyClass
{
public T MyProperty<T>
{
get;
set;
}
}
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
Orion: Integrate more C-Omega stuff. (Like, ?, +, *, !) and inline XML and inline XPath

See my later post on how I think we could do this better rather than having one uber laarge language that tries to do everything :-)

Which method do you prefer?
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
Cyrus & Cleve:
You are probably talking about macros like these one
http://nemerle.org/macros.html

Fully extensible compiler plugins, which can also extend language syntax, algorithmically traverse object model of assembly adding inheritance relations, methods, classes, inlige algorithmically generated code at any place
Anonymous
June 21, 2004
Ron: Thanks for the explanation. I'll keep that in mind.
Anonymous
June 21, 2004
Orion: Const is useless.

J/K!!!!!

I would love const too. I understand that we'd need to do work with the BCL. But I think we should do it because it's so beneficial and because it would help us find bugs with our existing code. I'm sure that adding const would reveal these problems and would prevent futures one from coming up, so I see it as being worth it.
Anonymous
June 21, 2004
Aleksander: XCode has a similar feature (with incremental find). It rocks. I want it in VS.
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
The ability to use several programming languages inside the same assembly is indeed a long term goal I would try to achieve. Yes, .NET has made it possible for several languages to "communicate", but when you want to have two classes that each reference the other you're out of luck. You have to create them in the same language. And I've come across several cases where I had to compromise structure of the solution because of this. If this would be possible then I'm completely for the idea that VB.NET and C# have different functionality. Until this is possible I'd like them to have similar power.
Anonymous
June 21, 2004
Kavan: Excellent point. I'd never considered that.
Anonymous
June 21, 2004
Geoff: I'm going to have to fish out my senior thesis. That's exactly what it could do (switch between languages like java/perl/etc. ;-) )

I'm not going to rant anymore because I want to hear other opinions on this. However, we do have strong beliefs on this. If we make languages the same then suddenly C# cannot move without thinking about what VB developers would think of this. What if we want to add more features that most VB users absolutely hate?

The things that Orion/AT have suggested could fall into that camp. New operators like !+? appearing all over the place (or in vb adding new strange keywords like "OneOf" or "OneOrMany").

By making the languages the same, we can no longer move in different directions, (which we're already doing) and which we thing would be the best thing for most of our users.

Note: Not all of users, just most. I do not believe that there is one language to rule them all. I see there being many languages with differetn strengths weaknesses, and a good programmer will be able to pick them up and use them well to solve the problem at hand. It's the old saying about a carpenter and his tools all over again.

Again: I want to assure you, if our users to end up wanting something badly enough and canshow justification as to the benefit they would recieve, then we will add a feature. It may come a version late, but you end up with languages that have features that benefit everybody but without features that most of the developers don't want.

I.e. a central core that is very similar, but with other features there that you see when you go beyond the surface that make the languages very different.
Anonymous
June 21, 2004
"Enforcment of rules: FxCop will do that for you.
yeah - but I want Microsoft to follow the rules
no more sealed classes
no more designing dead-ends into the framework
everything should be extensible, and/or composable, or replaceable"

Yeah, peeve of the day: XmlAttributeOverrides. I want to generate my overrides as they are asked for. As it is, I have to traverse over 20-30 large assemblies reflecting on the types and members therein, building a way-overly large set of XmlAttributes.

XmlAttributeOverides.Item in non-virtual, so theres absolutely nothing I can do. Its not a show-stopper, but its a fine example of what could be safely user-hookable, but instead turns out to be a dead-end requiring a work-around.

Ok, so this isnt an example of the "sealed" problem, but it is an example of a bunch of methods that could belong to an interface or be declared virtual.

Let me modify my rule.....

Every public method must be declared virtual unless it is also declared as patr of an interface.
Anonymous
June 21, 2004
Damien: agree 100%. Actually, scratch that. I agree 1000%.

I can't stand it when i run into that exact same issue.

If it helps, my code only passes around interfaces so you're free to do whatever you want. This often times involves me taking BCL types with no interfaces, and creating an interface an a wrapper class that implements that interface that will then call into the underlying BCL type.

We call them ThinWrappers and I hate having to do that. But it's the only way to get things to work sometimes. Sigh...
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
Support for the object type in the XML Serializer

Also, if I want to serialize a class, but not deserialize, I still have to write set properties for all the properties I want to serialize. It will only work with public fields and properties with both get and set operations. That has been problimatic enough that I had to abandon the XmlSerializer. I shouldn't have to rewrite my class to accomodate the XmlSerializer.

Also fix the inconsistency with XmlRoot versus the methodology for declaring other types of element. Declaring the name of the root element along with its namespace should be part of the constructor. That way, any class can be root without having to worry about declaring it to be so.

Orion Adrian
Anonymous
June 21, 2004
Orion: Can you give me an example of when you would want to serialize something but not deserialize it?
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
Orion: I'm not sure what you mean "any method that uses a property should use a field" could you explain a bit more.
Anonymous
June 21, 2004
Cyrus: Sure... let's say I want to create an XML log. I don't need to read in the log, but I need to write it out.

Also if I want to serialize something like the size of a collection (say it's very large and that information would be useful without having to parse the whole thing).

Basically anything that's computed rather than stored doesn't have a set property, but I still might want to serialize it.

Orion Adrian
Anonymous
June 21, 2004
Cyrus: Basically, in my mind a property is just a fancy field.

I should, and often do, create public fields when I don't have any restriction checking to do on it. But I get hit by the few methods in the CLR that only operate on properties.

Properties should be a way to
a) add restriction checking
b) abstract the data store

So if I need neither, I can go ahead and use a public field. It's nice, tight code. So everything that works on properties should also be able to work on fields.

Orion Adrian
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
oh... and maybe my hands are wringing :)
Anonymous
June 21, 2004
Cyrus: the example is too long. Should I post it here?

mailto:aleksei.guzev@bigfoot.com
Anonymous
June 21, 2004
Ability to define fields within properties, so instead of:

type x;
public type X
{
get { return x; }
set { x = value; }
}

you could type something like (lots of options for different syntax here of course):

public type X
{
store { type x; }
get { return x; }
set { x = value; }
}

or just:

public type X
{
type x;
get { return x; }
set { x = value; }
}

There are some fields that are so linked to the property definitions that they should syntatically liked to the property. I accomplish the same thing in my code now by wrapping the field and property in a region but it would be nice not to have all that extra stuff in the code.

Also, there are many times that I create public read, private write properties such as:

protected type _x;
public type X
{
get { return _x; }
}

then whenever I need to initialize X, I just reference _x directly (usually in one place) but this is messy. It would be much cleaner if the following syntax was available:

public type X
{
type _x;
get { return _x; }
protected set { _x = value; }
}

then I could still assign to the property inside the class while keeping it read only to external code.

One possible additional feature of the above syntax that would further protect the field storage is to make any fields defined within the property unavailable to code even within the same class. That way you would be sure that all access to the field is done through the getter and setter and never directly on the field.
Anonymous
June 21, 2004
Orion: I see. I was thinking just the binary serializer. I agree with you on the XML Serializer. Writing should only need your getters. Readers should only need your setters.
Anonymous
June 21, 2004
JimG: Protected setters are available in C# 2005.

Aleksei: Email it to me. Thanks!
Anonymous
June 21, 2004
Cyrus: Great to hear about protected setters in C# 2005. Is storage of fields in property syntax and the hiding of fields from anything other than the getter and setter of the property coming as well? One can hope <g>
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
Darren: where's the list of features :-)
Anonymous
June 21, 2004
darren: I'll pass on your feedback to the VB team (and i'll see if they havea blog so you can talk to them yourself).
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
Cyrus: When I said that saving typing is not really my concern, I meant for this particular feature request. Of course I'm drooling at all of the new features coming out that will save me gobs and gobs of keystrokes. Keep those features coming! <g>
Anonymous
June 21, 2004
Cyrus, I'm just grasping at straws here but doesnt a Thread in .net 2.0 track ExecutionContext, such that a second thread can call back into the main thread? I havent had an opportunity to peruse the documentation on System.Threading.Thread, or System.Threading.ExecutionContext (or SynchronizationContext, etc.) to see how all of this works. But as far as I can tell you should be able to synchronize an async thread with the calling thread using these contexts. I would imagine an "async/sync" set of keywords to provide compiler expansion similar to how i've heard "yield" works on iterators.

From a WinForms point of view it is a pain to write multi-threaded apps that update the UI, and you have to go through a lot of workarounds to make this happen. IMHO C# could stand some better features to make multi-threaded development easier. To me:

public class MyForm : Form
{
...
private async void SubmitBatch(DataSet batch)
{
... some long running process ...
sync
{
this.Text = "50% complete.";
}
... more work ...
sync
{
this.Text = "Done";
}
}

private void submitButton_Click(object sender, EventArgs e)
{
... compose dataset...
this.BeginSubmitBatch( ds, delegate { MessageBox.Show("Completed!"); }, null );
}
}
I think it's a bit cleaner than either writing your own IAsyncResult and having to deal with your own threading. the System.ComponentModel.BackgroundWorker seems to give you the kind of functionality you might need but it seems so over bloated for this kind of need. It also doesnt give you the true Async methods that are used throughout the framework. If i can create a delegate that automatically has an "Invoke", "BeginInvoke" and "EndInvoke", why can't i do the same for a method on a class or struct?
Anonymous
June 21, 2004
JimG: Interesting take on the property. But if that is the case, you might want to actually consider using a class to accomplish that goal. If encapsulation of state is important, then it would accomplish that the best way.

something like:

IProperty<T> {
T Value { get; set; }
}

...

IProperty<int> ageProperty;
int Age {
get { return ageProperty.Value; }
set { ageProperty.Value = value; }
}

then if anyone every actually tries to use age (like "ageProperty = 5") then they will have a problem.

---

I'm not disagreeing on this though. We will look at this and consider it carefully given the amount of requests we've had
Anonymous
June 21, 2004
Ron: In C# you can pass a method to something that expects a delegate and we'll automatically create the new delegate for you. Would that work?

i.e. instead of having to do:

new Thread(new ThreadStart(someMethod)) you can do:

new Thread(someMethod)
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
Ron: I gotcha now :-)

Very interesting idea. It syncs (no pun intended) with the kind of code hiding that anonymous delgates/iterators does for you.

really interesting idea!!
Anonymous
June 21, 2004
Will the 'async' block in the example have acces to local variables of SubmitBatch method? What objects actually can live in this block an dwhat objects are visible from this block? Could the same co-routine behaviour be achieved with anonymous delagtes passed to SubmitBatch as parameters?
Anonymous
June 21, 2004
XML Comments
-----------------

1. The smart-tag for renaming a parameter should also modify any corresponding <param name="parameter_name"> tag.

2. The auto-generation of xml comments by typing /// above the type/member should use the templates functionality so it can be customised.

3. A cref syntax that points to all overloads of a method - something like <see cref="SomeMethod(*)"/>

At present, the compiler always resolves to a specific overload, which makes it impossible to link to an 'overloads' page.

The current xml comments spec states that methods without parameters should not have parenthesis in the generated xml. If this were reversed, then documentation generators could resolve to the specific, no parameter, method when the parentheses are present, or to an overloads page if no parenthesis exist.

4. A quick way to collapse all code comments. This would make code navigation a lot easier.

5. Some way to add a custom xsd or other mechanism to make the xml comments intellisense aware of user-defined tags.
Anonymous
June 21, 2004
I have posted an example on class for classes
Anonymous
June 21, 2004
Aleksei: Are you talking about System.Type? If so, I'm not sure what you're actually asking for...

I'm really sorry. Can you provide an example (email me if you want) that shows what you would like to be able to do and what you are unable to do to now.
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
About the VB/C# difference in features. One must also remember that language choice is not always up to the developer. Employers are hiring .Net developers, not C# or VB developers, and then lang choice becomes a 'strategic' decision. The two langs should be equally powerful. Make them use one compiler, as stated above!
Anonymous
June 21, 2004
Every language has its goal. Employers should choose laguage according to the task, but not to their preference.
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 21, 2004
The comment has been removed
Anonymous
June 22, 2004
Cyrus, by macros I just mean VS macros. Drop VBScript or any other script for that matter. I will be happy if I never have to use a scripting language again.

I think you thought I meant some sort of macro like the old c preprocessor macros. No I dont want those. But I think someone mentioned attributes for interfacing with the compiler. That would be awesome, instead of just adding some metadata. I know the compiler treats some attributes special and generates special code, if you let us do the same (maybe a special base attribute CompilerAddinAttribute or something) that has methods to add some IL to the current attribute target, that would be incredibly powerful.

The guy that mentioned all the xml comments is brilliant. If you rename a param, the xmlcomment should be changed automatically.

On the VB == C# thing, I see what you mean that maybe the primary users of one language will not want some of the features. So maybe you need to do a better job of figuring out which features they DO want. So maybe VB guys dont want anonymous delegates, but when you add 2 huge features like Edit and Continue and the My classes, us C# guys groan because we want them too. Now we have to wait for another release cycle to get them. This might be as simple as shorten your release cycles, since then if you do give one camp a feature and you get grief from the other camp, they dont have to wait too long for you to make it up to them.
Anonymous
June 22, 2004
Kevin: Rename will fix up xml doc comments

Other suggestions added to the main list.
Anonymous
June 22, 2004
The comment has been removed
Anonymous
June 22, 2004
I read a lot of people asking for help defining properties and their backing stores.

The examples, without fail, look something like this:

int _x;
int X { get { return this._x; } set { this._x = value; } }

I keep asking myself, what value there is in having a property declared like that. It serves no function whatsoever.

Actually, I take that back. It serves one function - a PropertyGrid wont display fields.

The only other use I can think of is for providing read-only-ness or write-only-ness.

int _x = 45;
int X { get { return this._x; } }

The other usefull traits of a property are that it can be declared virtual, where fields cannot, and that a property getter/setter can perform more work than than simple assignment.

Have I missed anything?
Anonymous
June 22, 2004
Damien: There is a purpose in that. By encapsulating your state you are making sure that in the future you can change the behavior without anyone breaking you.

If you use a read/write field and then change to a property in the future then all code compiled against your old code will fail.

Note: you may also be implementing a property because it was declared in an interface. In that case you might just want it to be one of htese simple properties that people have mentioned.
Anonymous
June 22, 2004
I have started my own blog to not flood this thread with my ideas being sometimes impractical :(
http://language-guzev.blogspot.com/
Anonymous
June 22, 2004
using <class> is like with <an object> in Pascal. And I think there is a situation where such a feature will be useful.

The foreach statement always involves declaration of a local variable:

foreach( XmlElement element
in doc.SelectNodes(xpath) )
{
Console.WriteLine( "{0} of type {1}",
element.Name,
element.GetAttribute("Type"));
}

How often You name the variable with i? While there is always the special variable in the foreach statement it's possible simply omit its name:

foreach( XmlElement in doc.SelectNodes(xpath) )
{
Console.WriteLine( "{0} of type {1}",
Name, GetAttribute("Type") );
}
Anonymous
June 22, 2004
using <class> is like with <an object> in Pascal. And I think there is a situation where such a feature will be useful.

The foreach statement always involves declaration of a local variable:

foreach( XmlElement element
in doc.SelectNodes(xpath) )
{
Console.WriteLine( "{0} of type {1}",
element.Name,
element.GetAttribute("Type"));
}

How often You name the variable with i? While there is always the special variable in the foreach statement it's possible simply omit its name:

foreach( XmlElement in doc.SelectNodes(xpath) )
{
Console.WriteLine( "{0} of type {1}",
Name, GetAttribute("Type") );
}
Anonymous
June 22, 2004
The comment has been removed
Anonymous
June 22, 2004
Darren: Your post was too long. There's no way I'm going to read all of that. Jeez.

J/k ;-)

Thanks for the feedback! I'll respond soon.
Anonymous
June 22, 2004
Darren: Ok. 1 at a time.

==2== expose syntax colouring engine ====

I would love some way of adding my own coloring things - for instance, anything starting with the word Test in a different color :)

Sounds like a great idea. If we can we'll try to make it a plugin architecture so you can replace our implementation (or subclass it, etc.). Can't gaurantee anything about if we'd support this or not though.
Anonymous
June 22, 2004
The comment has been removed
Anonymous
June 22, 2004
Darren:
==4== intellisense shows base constructors when typing ====
==17== directly declare new object without doubling up =====

I'm a big believer that the IDE should provide help in these areas. Similar to how += will prompt you to create a delgate.

so as you type:

"Blah"

you'll get a tip saying: "hit tab to insert "Blah blah = new Blah();"

After hitting tab you'll end up with the cursor between the ()

Things like that.
Anonymous
June 22, 2004
Darren:
==5== "expose" keyword ====

I dont' get it :-)

More examples.
Anonymous
June 22, 2004
Darren:
==6== information about code, where we are coming from ====
==7== stack trace with parameters =====
==9== interface into the code parser ====
==20== pre-post condition specifiers ====

These are all part of a big category of giving you greator control over your code. We're thinking about this a lot and how doing this the right way could get all of this for you for free
Anonymous
June 22, 2004
Darren: ==8== get rid of regions for implements ====

Good idea. Goes into giving the user control over the code we spit.
Anonymous
June 22, 2004
Darren:
==10== tuples

I want them :-)

==11== "delegate" equivalents for properties

Yup. This kills me too.

==12== method scoped variables

Hrmm.. Interesting idea. Looks like you're trying to encapsulate a field so only this method can access it. Seems like you should have a class do that encapsulation instead.
Anonymous
June 22, 2004
Darren: == 15 == Functions in module scope =====

How do you solve the name resolution problems that arise? We're trying to avoid all the issues you run into with C, even if there is a slight extra cost to it.
Anonymous
June 22, 2004
Darren: ==19== stop controls being removed from the form ====

The WinForms team has worked a lot on this. It was one of their highest priorities. They worked with all teams to improve the robustness of the designer immensely and I hope it shows for you

==1A== returns from anonymous methods =====

I need an example. I just do:

delegate { return 4; }

And that works :-)
Anonymous
June 22, 2004
Darren: ==1B== vi commands =====

Nah. Tons of devs here ask for vi and emacs modes as well :-)

==1C== inference of object array types =====

I think that's one of those low benefit changes. Plus there are issues with type inferencing. But we'll look at it for sure

==1E== delegate inheritance matching ====

Whidbey delegates support co/contravariance. So you'll be all set.
Anonymous
June 22, 2004
Darren: ==1F== readonly method members ====

I'd like that too.

==21== backing store for properties ====

We can that request so much that I think it'll have to be looked at again. There are strong arguments for it, and not too many against it.

Suggestions on preferred syntax are appreciated.
Anonymous
June 22, 2004
The comment has been removed
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
Anonymous
June 23, 2004
I have tried to explain formatting with CSS on
http://language-guzev.blogspot.com/
Anonymous
June 23, 2004
The comment has been removed
Anonymous
June 23, 2004
Aleksei: I blogged about formatting with CSS as well earlier.

Check back through last month's posts about ideas for the next formatting engine.
Anonymous
June 23, 2004
Wesner: I've been coding for a long time and I'm an avid fan of the history of coding. This issue has been raised year after year after year and coding still remains equally (if not more) important in the process.

If things change then we'll roll with it and we'll work hard to create great developer tools that target those changes.
Anonymous
June 23, 2004
==24== event stores START initialized ====

anyone recognize this code?
if (EventX!=null)
EventX( this, firstParam, secondParam);

Of course, every now and then we all forget the if - and eventually get a null reference exception.
Now - when you say EventX += myHandler - you don't first do EventX = new EventX, do you?

Any chance of either
a) automatically initializing an event, when you define event x;
b) behind the scenes inserting the above if statement when you try to cause an event?

The only code I can imagine which could be broken by (a) is code that does something different if no-one is listening on the event [and anyone who did that deserves pain] and no code at all could be broken by (b) - in fact lots of existing code would be unbroken...

Please! can we ditch the null test?

==25== event delegates ====

I don't know about you, but I would NEVER let anyone re-use a delegate definition for an event. reasons:
a) you end up with people dodging strong typing, and casting their eventargs/sender values to what they were expecting, because they were too lazy to create their own delegate (although it would be nice to see a Generic control, which sent an event Click(T sender, EventArgs...) :)
b) you get much less compiler support to change everything when you suddenly decide you want to send one more value to the event handler...
c) you're royally rooted if you've created three events that currently look the same, so someone has pumped them all to the same handler - then you go and decide one of them needs extra information.

so, at the moment, I will always have the following code:

public delegate void LockedHandler( LockButton source );
public delegate void UnlockedHandler( LockButton source );

public class LockButton
{
event LockedHandler EventLocked;
event UnlockedHandler EventUnlocked;
}

(I hate it, but I prefix every event with the word "Event" so that we don't forget to put the "if" in if anyone calls the thing)
it would be really nice if we had the option (which would have exactly the same effect) of doing this:

public class LockButton
{
event void EventLocked( LockButton source );
event void EventUnlocked( LockButton source );
}

which basically creates delegates called LockButton.EventLocked, LockButton.EventUnlocked, and declares two events with the respective delegates...

the syntax is FAR more intuitive, the implementation safer, and it encourages people strong typing their delegates, instead of sending the "object sender" - I mean I understand why such a horrible compromise was necessary, but we have generics now - we don't need to ever use object again! [kidding]
Anonymous
June 25, 2004
Cyrus,

A summary of this would be great.
Anonymous
June 25, 2004
JD: I will post a summary next week. I'm still getting feedback. It's going to take a while to get it al together :-)
Anonymous
July 25, 2004
Create an Add-In features will be great.............
Anonymous
September 01, 2005
Your blog is very interesint
Anonymous
May 26, 2009
PingBack from http://castironbakeware.info/story.php?title=cyrus-blather-what-features-would-you-like-in-the-next-version-of
Anonymous
June 08, 2009
PingBack from http://insomniacuresite.info/story.php?id=1842
Anonymous
June 09, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=8161
Anonymous
June 13, 2009
PingBack from http://barstoolsite.info/story.php?id=3046
Anonymous
June 18, 2009
PingBack from http://thestoragebench.info/story.php?id=9895

Partager via

What features would you like in the next version of Visual C#?

Comments

Ressources supplémentaires