|
@4-10, were talking C# the language, version 4.0. Your points 4-10 are all framework features, not language features.
|
|
|
|
|
Sorry, that is true... except some of them are IDE features and not .NET ones
|
|
|
|
|
Yortw wrote: 8. Fix for the (very rare) bug caused by compiler optimisations on the String.IsNullOrEmpty function.
I thought they already fixed that in 3.0 or 3.5.
|
|
|
|
|
Last time I checked the bug report on connect.microsoft.com they had marked it as closed, "Won't Fix"... and I thought that was after 3.5 was released, but I could be wrong.
|
|
|
|
|
Sorry, you are correct, they fixed it in 'orcas'.
|
|
|
|
|
I'd like to see member variables treated as if they were in a class-lifetime 'using' statement.
I miss the deterministic destructor from c++, but this would at least allow me to put the class in a using statement and have its member variables' dispose methods called implicitly.
|
|
|
|
|
I guess I just want the default implementation of Dispose() to call Dispose() on all the member variables.
|
|
|
|
|
The ability to include directly MSIL in code. Not strictly necessary but I'd love to be able to. Be it for method bodies or to describe MSIL streams (anyone using Emit knows what I'm talking about).
Contracts. Oh they would be so nice
|
|
|
|
|
Namely i'd like to see the following:
1. Implementing Interfaces by delegation to fields
2. Anonymous type return values
3. Some Duck-typing or Structural Subtyping support
4. Safe Null Dereferencing Operator as someone already mentioned (eg) Customer?.Orders?.Last?.Address
I have expanded more on this some time ago here:
http://anastasiosyal.com/archive/2008/07/19/4-features-for-c-4.0.aspx
|
|
|
|
|
Anastasiosyal wrote: 3. Some Duck-typing
From what I've read about duck-typing, I don't think it's a good idea; it has no way of verifying the "like a duck" part.
If I have an object that walks and quacks, but not like a duck you'd better not call it a duck.
|
|
|
|
|
A lot of the stuff from Spec#. At a minimum - preconditions, postconditions and invariants.
Kevin
|
|
|
|
|
A couple of things I would like is better control over memory. The automatic garbage collection is nice and I understand that it's usualy better just to let it be so it can collect when needed, but in some cases I know the memory can and must be freed like when processing a large import file. Also I would like to be able to "Destroy" an object in certain situations. By that I mean to have one method that can nullify all refrences to a particualar object.
Another thing would be multipule inheritance, or at least some psuedo-composite type scenario. My company seels a website management tool which runs as a smart client, so I write a lot of UI code that is shared between web and windows. We have our own MVC style system so much of the "Controller" and "Model" code is common to both web and win, but we also have several methods we have to add to both web and windows controls to support that system.
Our only option now is to use interfaces, but 90% of the implementation of those interfaces for each control could be shared, but is currently copied since both our web and windows controls can't derive off of a base class.
|
|
|
|
|
Member 3976638 wrote: A couple of things I would like is better control over memory. The automatic garbage collection is nice and I understand that it's usualy better just to let it be so it can collect when needed, but in some cases I know the memory can and must be freed like when processing a large import file. Also I would like to be able to "Destroy" an object in certain situations. By that I mean to have one method that can nullify all refrences to a particualar object.
In .NET, nulling an object does not release/free any memory used by that object. In your example of processing a large import file, a lot of how you interact with the file will determine the memory used, but if you're using streams at all you should be disposing of those streams when you are finished with them. Also, keep in mind that if you load the entire file into memory at once and the resulting object is over 85K in size it's ending up on the large object heap which has different rules with respect to how the GC runs. If you absolutely need to reclaim the memory, you can call GC.Collect(int generation, GCCollectionMode mode) overload and use a GCCollectionMode.Optimized, which will only run the collection if the GC determines it is needed or GCCollectionMode.Forced, which will force a collection. If you do things like this, you need to be very careful about it as every time you run a collection cycle your application's main thread (and any threads it creates) will be frozen during the cycle.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Hi,
I wrote down my wish list for future versions of C# in my blog:
My Complete C# 4.0 Wishlist[^]
I'd love to get your feedback on any of these suggestions.
|
|
|
|
|
Hi,
Regarding the idea of tuples, I'll have to strongly disagree with you on that one.
I wrote all about it here: Tuples are Evil[^] !!
Specifically for your example, I fail to understand why you think your suggestion:
public int,int MinMax(int[] numbers)
{
int min, max;
min=whatever
max=whatever
return min, max;
}
is better than the existing:
public MinMax(int[] numbers, out int min, out int max)
{
min=whatever
max=whatever
}
The version with out parameters is shorter to write (!), you don't need to declare min and max in your method and you do not need to return them, just assign max=whatever and min=whatever like you have to do in the tuple version anyway. It's also safer since the compiler will make sure you assign something to each out parameter.
and more importantly- the version with out parameters is more informative to the user!
Let's check out the usage of each version:
tuples version:
int min, max;
[min,max] = MinMax(new [] {1,2,3});
out parameters version:
int min, max;
MinMax(new [] {1,2,3}, out min, out max);
The usage is pretty much equivalent, except that in the out parameters version you will get helpful auto completion about the parameter names, so it's easier to write! The only thing that keeps the out parameters version from being perfect is the lack of support for optional parameters, which is #1 on my wish list for C# 4.0.
|
|
|
|
|
I'd like to see them fix automatic properties.
A lot of people have complained that there should be a way to set the default like...
public int A { get; set; default { return 1; }
But i think they should take it further. I'm a big fan of the CSLA framework hence i have a lot of properties following
public int A
{
get
{
CanReadProperty(PropertyNames.A, true);
return m_a;
}
set
{
CanWriteProperty(PropertyNames.A, true);
if (!m_a.Equals(value))
{
m_a = value;
PropertyHasChanged(PropertyNames.A);
}
}
}
(I know new CSLA is different but it's still just as much repetition)
I would love to be able to say
public int A { get; set; from CslaProperty }
where CslaProperty is a template. It's sort of like adding inheritance to Properties.
I'd also like to be able to take it further so you could say...
public string A
{
get;
set
{
if (value == null)
value = "";
@templateBase = value;
}
}
This would stop the really annoying thing about automatic properties where you use them, then you want to make a minor change and have to go to the trouble of making a full property
|
|
|
|
|