C# 4.0

[Yortw]

Sorry, you are correct, they fixed it in 'orcas'.

[Scott Dorman]

Actually, I think the whole problem would be better solved by lifting the . operator in the same way they did for some of the other operators to handle nullable types. It is essentially making nullability a true first-class language citizen, whereby accessing a property or calling a function on a null object simply returns null rather than a NullReferenceException.

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

[Scott Dorman]

Tuple support is certainly nice but there are other ways to handle this. Simply having some predefined Tuple<T> type classes like we have with Func<T> and Action<T> would be more than sufficient, I think.

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

[Scott Dorman]

Optional parameters will probably be there. Const paramters are doubtful although it would be nice, at least as a compile-time check.

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

[Scott Dorman]

Giampaolo Papotti wrote:

And what about the annoying lack of default in parameters? I'd like to see c# designers and gurus dealing with Office PIA... I'm sure they would have a private build of csc.exe with default parameters implementeed .... InvokeExcelStuff(theOnlyNeededParameter, null, null, null, null, null, null, null, null, null, null, null, null, null, null....)

This should become simpler...stay tuned.

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

[Scott Dorman]

Extension methods are just like any other language feature...they have the ability to be misused/abused (and not just from newbies, but by anyone). I don't think that's a good reason to not include a feature or we would end up writing assembly again. How do extension methods force you to write bad code? If you don't want to use them, don't use them. It's that simple. Yes, there should be more guidance on how to properly use/write extension methods (which is coming) and possibly some better compiler support to enforce that. I disagree with the ability to add extension methods in the same namespace as one that's defined by Microsoft. This isn't actually polluting a namespace but rather polluting a type, but that's kind of the idea behind extension methods. BTW, other languages have similar features as well and are usually called Mix-Ins. The thing to remember about extension methods is that they are nothing more than an alternate syntax for calling a static method on a static class. They are defined in exactly the same way (with the addition of the "this" keyword in the parameter list) and compile to the exact same IL as if you were to call it the "normal" way (i.e., as a static method on a static class and pass in the object you want to modify/act on). Calling it as an extension is a more natural syntax, but it's all syntax sugar/compiler magic. Extension methods do not have access to the internal state or variables of the class they are extending. You also can't use an extension method with the same signature as a native method...you can declare one but there is no way to actually override the native method with your extension and it won't show up as an available method in intellisense so there is no way to call it except as a static method on a static class, in which case you no longer have the extension syntax and it's completely clear which method is being called.

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

[Scott Dorman]

That would be very nice to have.

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

[Scott Dorman]

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

[mvonballmo]

There is an extension of C# available that provides some help in this area: spec#. I haven't used it myself, but I'm a big fan of Eiffel, which has deep design-by-contract support. Spec# includes notation to indicate that a variable or parameter can never be null. BTW, if you're really interested in further reading on features for C#, the Eiffel language is a good place to start, as a language that has true generics since inception as well as tuples, anchored types, parameter covariance and many other interesting goodies.

[Roy Peled]

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.

[Roy Peled]

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;
// Code to calculate min/max
min=whatever
max=whatever
return min, max;
}

is better than the existing:

public MinMax(int[] numbers, out int min, out int max)
{
// Code to calculate min/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.

[Chris_McGrath]

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