Ideas for C# 5.0

Minh said:

I want to have "endif"

Is this a serious suggestion?

TommyCarlier said:

Bass said:

*snip*

var i = 123L; // the type of i is long/Int64

I ment to say that the compiler can figure out if a literal should be an Int32 or Int64 based on it's size. My bad.

stevo_ said:

I think first class tuples would be useful, I would imagine extension properties make it in as its been noted that they actually agreed on a specification for how to do it, just had to cut it for 4.0 in order to shipit.

 

Not sure about enumeration, a tuple is only a sequence in a syntactic sense, theres plenty of contexts for how you can iterate something, and I think there needs to be proper thought into what should be considered a native sequence to the language.. best bet is, does it really add anything? no, then its not worth introducing additional behavior.

IIRC they decided the specification was the wrong thing and to go back to the drawing board.

stevo_ said:

I think first class tuples would be useful, I would imagine extension properties make it in as its been noted that they actually agreed on a specification for how to do it, just had to cut it for 4.0 in order to shipit.

 

Not sure about enumeration, a tuple is only a sequence in a syntactic sense, theres plenty of contexts for how you can iterate something, and I think there needs to be proper thought into what should be considered a native sequence to the language.. best bet is, does it really add anything? no, then its not worth introducing additional behavior.

It adds composability (direct use of tuples for LINQ) - but you're right, it needs to be thought out if there are costs involved, conflict cases - and whether to only allow it for homogeneous tuples: for this case what would be wrong, I don't see anything.

More complex data structures, such as R-Tree's

Maddus Mattus said:

More complex data structures, such as R-Tree's

As a language feature?

stevo_ said:

Maddus Mattus said:

*snip*

As a language feature?

yeah, you are right. It would make it a .Net 5.0 feature not a language feature.

But I would still like it

First class dependency objects and properties;

public dependency class Person
{
	public dependency string Name 
	{ 
		get;
		set; 
		default { return "John Doe"; }
		change { Console.WriteLine("Old: {0}, New: {1}", oldvalue, newvalue); }
	}
}

instead of

public class Person: DependencyObject
{
	public static readonly DependencyProperty NameProperty = DependencyProperty.Register(
		"Name", typeof(string), typeof(Person), new PropertyMetadata("John Doe", OnNameChanged));
	
	private static void OnNameChanged(DependencyObject sender, DependencyPropertyChangedEventArgs args)
	{
		((Person)sender).OnNameChanged((string)args.OldValue, (string)args.NewValue);
	}
 
	public string Name
	{
		get { return (string)GetValue(NameProperty); }
		set { SetValue(NameProperty, value); }
	}
	private void OnNameChanged(string oldvalue, string newvalue)
	{
		Console.WriteLine("Old: {0}, New {1}", oldvalue, newvalue);
	}
}

Would be nice if something like this could also work with INotifyPropertyChanged, IDataErrorInfo and IEditableObject.

Vriff Polo said:

First class dependency objects and properties;

 

 

public dependency class Person
{
	public dependency string Name 
	{ 
		get;
		set; 
		default { return "John Doe"; }
		change { Console.WriteLine("Old: {0}, New: {1}", oldvalue, newvalue); }
	}
}

 

 

instead of

 

 

public class Person: DependencyObject
{
	public static readonly DependencyProperty NameProperty = DependencyProperty.Register(
		"Name", typeof(string), typeof(Person), new PropertyMetadata("John Doe", OnNameChanged));
	
	private static void OnNameChanged(DependencyObject sender, DependencyPropertyChangedEventArgs args)
	{
		((Person)sender).OnNameChanged((string)args.OldValue, (string)args.NewValue);
	}
 
	public string Name
	{
		get { return (string)GetValue(NameProperty); }
		set { SetValue(NameProperty, value); }
	}
	private void OnNameChanged(string oldvalue, string newvalue)
	{
		Console.WriteLine("Old: {0}, New {1}", oldvalue, newvalue);
	}
}

 

Would be nice if something like this could also work with INotifyPropertyChanged, IDataErrorInfo and IEditableObject.

 

There is a lot of activity around dependency injection, dependency properties etc. I wonder if they really constitute the way of the future especially with Rx on the horizon. Hmm...

Dependency injection is really a different concept to the dependency system wpf and wf use, I don't think you really intend for the dependency system to be part of the core language feature, its really pretty specific.. I think you may be more interested in something more like 'first class properties', where you could pass around a property as an object, and be able to do more sophisticated things by default, such as change notifications and binding.

I think this is something too specific for a language feature personally, but its something that could be implemented by a library if we had a standard way to do post compilation weaving like postsharp does.

Tuples, ct'd

A progression of signal amplifications vis-à-vis noise reductions

// absolute noise
Tuple<int, int> Abs(int x, int y)
{
    return Tuple.Create(Math.Abs(x), Math.Abs(y));
}
// less noise
(int, int) Abs(int x, int y)
{
    return (Math.Abs(x), Math.Abs(y));
}
// less noise still
(int, int) Abs (int x, int y)
{
    return Math.Abs(x), Math.Abs(y);
}
void test()
{
    // full noise
    Abs Tuple.Create(1, -1)
    // less noise
    Abs (1, -1)
}

In particular, this

void test()
{
    Abs (1, -1)
}

should also match up with this

Tuple<int, int> Abs(Tuple<int, int> p)
{
    return Tuple.Create(Math.Abs(p.Item1), Math.Abs(p.Item2));
}

Clearly this is nver going to happen but....

... what about saying "you know, we did a really good job on c# 4.0, so lets leave it for a while and instead of adding new features right away, lets see if we can look to adding stuff in five years time."

silverfrost said:

Clearly this is nver going to happen but....

 

... what about saying "you know, we did a really good job on c# 4.0, so lets leave it for a while and instead of adding new features right away, lets see if we can look to adding stuff in five years time."

 

Problem is, the world doesn't stand still just because you do. Witness Java-land and the great Scala. Not evolving is loosing.

Unnullability a la

    public struct Unnullable<T> where T : class
    {
        public Unnullable(T x)
        {
            if (x == null)
                throw new NullReferenceException();
            item = x;
        }
        public T Item
        {
            get
            {
                return item;
            }
        }
        private readonly T item;
    }

and used as such

    class Foo
    {
        int Bar = 3;
    }
    class Program
    {
        static void Main(string[] args)
        {
            var ufoo = new Unnullable<Foo>(new Foo());
            Console.WriteLine(ufoo.Item);
            Unnullable<Foo> baz; // error
            Unnullable<Foo> bax = null; // error
            Unnullable<Foo> box = (Foo)null; // error
            Console.ReadKey();
        }
    }

with built-in compiler support so we can simply write

var ufoo = new Foo!(); // type of ufoo is Foo! => Unnullable<Foo> 
Console.WriteLine(ufoo.bar);

Even without compiler support it will help catch nullness errors because in this case the compiler just translates ! to Unnullable - a kind of dual of ? which translates to Nullable. And with compiler support you may not even need to explicitly implement as Unnullable<T> although it will probably make the implementation easier.

And of course unnullable classes - where by default the class is unnullable.

It may seem a not very ambitious request, but what I would like to see in C# is the ability to declare variables in the guard expression of some statements. Some usage examples:

while ((int bytesRead = stream.Read (buffer, 0, buffer.Length)) > 0) {

   outStream.Write (buffer, 0, bytesRead);

}

if ((IDisposable d = someObject as IDisposable) != null) {

  d.Dispose ();

} else {

  Console.WriteLine("Cannot dispose objects of type {0}", d.GetType().Name);

}

switch (char c = charReader.ReadChar()) {

  case 'a':

  case 'b': {

     return c;

  }

  ...

}

It would prevent some name pollution and make porting code from C/C++ easier.

Blue Ink said:

It may seem a not very ambitious request, but what I would like to see in C# is the ability to declare variables in the guard expression of some statements. Some usage examples:

 

while ((int bytesRead = stream.Read (buffer, 0, buffer.Length)) > 0) {

   outStream.Write (buffer, 0, bytesRead);

}

 

if ((IDisposable d = someObject as IDisposable) != null) {

  d.Dispose ();

} else {

  Console.WriteLine("Cannot dispose objects of type {0}", d.GetType().Name);

}

 

switch (char c = charReader.ReadChar()) {

  case 'a':

  case 'b': {

     return c;

  }

 

  ...

}

 

It would prevent some name pollution and make porting code from C/C++ easier.

 

Doesn't seem too bad although I'd be cautious about importing C++ coding practices into C#.

exoteric said:

Unnullability a la

    public struct Unnullable<T> where T : class
    {
        public Unnullable(T x)
        {
            if (x == null)
                throw new NullReferenceException();
            item = x;
        }
        public T Item
        {
            get
            {
                return item;
            }
        }
        private readonly T item;
    }

and used as such

    class Foo
    {
        int Bar = 3;
    }
    class Program
    {
        static void Main(string[] args)
        {
            var ufoo = new Unnullable<Foo>(new Foo());
            Console.WriteLine(ufoo.Item);
            Unnullable<Foo> baz; // error
            Unnullable<Foo> bax = null; // error
            Unnullable<Foo> box = (Foo)null; // error
            Console.ReadKey();
        }
    }

with built-in compiler support so we can simply write

var ufoo = new Foo!(); // type of ufoo is Foo! => Unnullable<Foo> 
Console.WriteLine(ufoo.bar);

Even without compiler support it will help catch nullness errors because in this case the compiler just translates ! to Unnullable - a kind of dual of ? which translates to Nullable. And with compiler support you may not even need to explicitly implement as Unnullable<T> although it will probably make the implementation easier.

 

And of course unnullable classes - where by default the class is unnullable.

The real performance benefits from this [null checks] come in at the MSIL level, unfortunately, so spec# etc. is the only way to go. None of this namby-pamby, prittle-pattle, tittle-tattle type nonesense.

With regard to dependency injection, I think Prism is leading the way here, and from a library point of view, it makes sense and the team has really done a fantastic job. If you gave me the cash and the staff to build a high-class, modern application, Prism would be at the top of my list.

With regard to extension methods, you could pick a handful of your favorite static libraries, MessageBox.Show, Regex even Code Contracts and add them to your list. This will widen the scope for method name clashes, so i'm sure the BCL team will resist this somewhat.

Thats not to say there isn't some perspicacious thinking going on here, because there is.

vesuvius said:

exoteric said:

*snip*

The real performance benefits from this [null checks] come in at the MSIL level, unfortunately, so spec# etc. is the only way to go. None of this namby-pamby, prittle-pattle, tittle-tattle type nonesense.

 

With regard to dependency injection, I think Prism is leading the way here, and from a library point of view, it makes sense and the team has really done a fantastic job. If you gave me the cash and the staff to build a high-class, modern application, Prism would be at the top of my list.

 

With regard to extension methods, you could pick a handful of your favorite static libraries, MessageBox.Show, Regex even Code Contracts and add them to your list. This will widen the scope for method name clashes, so i'm sure the BCL team will resist this somewhat.

 

Thats not to say there isn't some perspicacious thinking going on here, because there is.

I'm quite curious as to how you'd create a more efficient representation than a struct wrapping a reference type, please elaborate.

Actually this is not about performance at all, it is about correctness.

I'm not very familiar with Spec# but believe it has syntax support for non-nullability. Does Spec# not use the off-the-shelf CLR?

As to extension methods, that's a different thread, this is about C# 5.0 ideas (but would welcome any discussion about anti-patterns there; I don't think Contract makes sense as an extension method cluster at all; it does make sense, however, to lift the methods out to be accessible without name qualification; MessageBox.Show, I don't know about that one; - but let's have that discussion in the other thread).