tags:

views:

244

answers:

7

... and things that you still look forward to seeing in the upcoming versions.

+1  A: 

This topic has essentially been covered here. It contains some very interesting suggestions indeed (a few of which are in fact noted to be planned for C# 4.0). Definitely worth reading through the whole thing.

Noldorin
Thanks, haven't seen that one.
Joan Venge
Yep, just started reading and some good stuff. Mine is more like things you always wanted, whether for C# 4, 5 or 6.
Joan Venge
+2  A: 

Property-scoped fields

public int N {
  private int n, m = 3;
  get { return n + m; }
  set { n = value; }
}

Chained null checks

if (document!RootNode!ChildNode != null) ...
Dmitri Nesteruk
You should extend that to chained logical expressions: if(x!y!z == 1), the ! probably isn't a good operator to use since it implies negation. Maybe the ^ would work for the operator but I forget if that's used as a binary operator
Chris Marisic
^ is XOR. I would envisage using , in this situation as it doesn't have another purpose in conditionals.
Jeff Yates
Maybe ? then, e.g., a?b?c
Dmitri Nesteruk
+1 for chained null checks.
Noldorin
+4  A: 

Multiple setters:

private Uri _linkUrl;
public Uri linkUrl
{
    get { return _linkUrl; }
    set
    {
        _linkUrl = value;
    }
    set<string>
    {
       _linkUrl = new Uri(value);
    }
}

//this of course works fine
MyObj.linkUrl = new Uri("http://stackoverflow.com"); 

// but I could also just do this:
MyObj.linkUrl = "http://stackoverflow.com";
Joel Coehoorn
But isn't this achieved with just implementing an implicit cast operator?
Jeff Yates
Yes, but that's a lot more code.
Joel Coehoorn
But not really. With this approach suggested, you have to do this for all properties that you want this behavior. Whereas, you only have to implement the cast operator once.
Jeff Yates
This also provides granularity: you may not want to do it _everywhere_. That could lead to bugs in other code.
Joel Coehoorn
I can see the benefit to only having it in certain cases, but I feel this is more likely to create a less intuitive development process than a really useful language feature. Once one place lets me do Uri's like this, I'd expect it everywhere.
Jeff Yates
Obviously, Uri is just an example. Perhaps you have another that is more appropriate and doesn't just feel like it's confusing semantics.
Jeff Yates
Actually I'll stay with Uri, but change the example a bit. Say you have a class with a property like this that also keeps context to a specific web site. You might want to create a relative Uri rather than an absolute, using that context as the base. You wouldn't want to also do that everywhere.
Joel Coehoorn
I can see that. Yeah. That would be useful. As with any language construct, there's room for abuse, but I can see that kind of situation being useful.
Jeff Yates
It would be a way of combining properties. In other situations you might write multiple property accessors or methods, but this gives a neat way of handing multiple types under one property name in a strongly typed manner, making for neater interfaces. I like it. Thanks.
Jeff Yates
A: 

Conditional/filtered event handlers:

class A
{
   public event EventHandler MyEvent;
}

class B
{
   int x;
   A classA = new A();
   public ClassB()
   {
     classA.MyEvent += new EventHandler(OnMyEvent).Where(x > 5);
   }
}

This would mean I only get events when the filter is matched. I could also envisage using other LINQ-style operators such as First() where you only get the event fired once and then never again.

For example, instead of writing:

   private void OnMyEvent(object sender, EventArgs e)
   {
      if (x > 5)
      {
         // Do stuff.
      }
   }

I can specify the condition where the handler is attached to the event. The compiler would insert a new handler behind the scenes with the condition applied based on the method I define. This way, i can define a single handler that is used with different conditions on multiple events rather than needing one handler per event just because I need a different condition or filter in there. There wouldn't be a need for any new CLR support - this would just be syntax changes.

I want language support for exception filters as well.

Update

I believe my "filtered events" concept can be created through the use of .NET 4 and the Rx framework.

Jeff Yates
As a part of the *language*?! I don't think that's such a good idea....
Justice
Why not? It would just be a nicer way of specifying conditions than putting it in the event handlers. The compiled MSIL would no doubt be the same, but it would make event rules clearer.
Jeff Yates
What you propose will lead to an unstable architecture, handlers are present or not dependent on some condition. Check that condition within the handler and there decide whether to react or not.
User
Seems like an 'extra' to me.
Dmitri Nesteruk
No, the handler is always present - it's just a way of specifying when you care for your actual handler to be called. It's syntactic sugar to take away the need to write conditions in your handlers.
Jeff Yates
Looks like no language change required for the filtered events. See my update. :)
Jeff Yates
A: 

Nullable strings

string? strx; 
strx.GetValueOrDefault(string.Empty);

Extension Properties

Same as extension methods but properties, would allow extending unowned code into fluent interfaces

objX.Is().Not.Something();

vs

objX.Is.Not.Something();
Chris Marisic
Since properties are translated into method calls by the compiler, I wonder if you could so this now via creative extension method names? Probably not, but I'll to try later.
Joel Coehoorn
Currently I'm using the first method but it just looks a little kludgey to me seeing Is(). vs Is.
Chris Marisic
The nullable string gave me a double-take for a moment, but I get it. Of course, you can do the GetValueOrDefault via an extension method now, right?
Jeff Yates
True Jeff, however without Extension properties I wouldn't be able to do the .Value or .HasValue properties, obviously I could do them as methods but I don't understand why they don't allow strings as nullable to start with since they emulate value types in every other way.
Chris Marisic
I guess it's because it would be extra work and strings already have the concept of being null, but I see your point.
Jeff Yates
-1 A string is a reference type. Making itn nullable makes no sense.
Noldorin
I disagree, even though string truly is a reference type the string functionality is meant for it to behave in every manner as a value type. This would be one of the reasons strings are immutable even though they reference types they really are also psuedo-value types. I should be able to apply the Nullable class to a string. If extension properties existed I would recreate it myself.
Chris Marisic
+1  A: 
  • Static extension methods and properties
  • Built-in arithmetic support in Generics
Joan Venge
A: 

"Friend" keyword from C++. It opens great possibilities in right hands.

User
The internal keyword and InternalsVisibleTo attribute already achieve this in a manner that I feel is far less dangerous than the friend keyword.
Jeff Yates
I disagree. I would like to have that possibility without putting the stuff in a separate assembly. As for dangerous, if a programmer does not have a clear mind, he will make a mess in any framework independent on how restrictive it is.
User
You can just use the internal keyword, thereby not needing to put the stuff in a separate assembly.
Jeff Yates