Expert to Expert: Erik Meijer and Anders Hejlsberg - The Future of C#

A few things I would like to see in C#:

• With regards to immutability, how about a freeze method, like in Ruby and implemented perhaps as an extension method of System.Object, that would allow you to make an existing instance of an object immutable? (Also a IsFrozen() method to determine if an object has been frozen) It already exists in a limited form with readonly, and it might be doable moreso now thanks to code contracts that could be used to enforce immutability at compile-time and run-time.
• Better literals for arrays, hash tables, and objects. Object and collection initializers are nice but not as succinct as in, say, Ruby or JavaScript.
• (Really a wish for LINQ) Enumerable.Empty, i.e., return an empty sequence. Silly to ask for something so trivial but it's missing! And of course it needs a nice literal...

Long term for .NET:

• SIMD instructions to support data parallelism in xPU computation where perhaps PLINQ code gets farmed out to the many processing units in your GPGPU (Cell, Larrabee) instead of the handful of processors in your CPU. This is something the Mono guys are already working on, if I understand correctly.
• More lazily evaluated library methods (where possible and enabled by the underlying Win32 API), e.g., DirectoryInfo.GetFiles() takes a awfully long time to load when you have 500,000 files in a folder -- where's the wrapper for FindNextFile?  Or how about lazily evaluated networking functions where implementing a TCP server is as simple as implementing an iterator?
  

some questions:

- what about static methods for interfaces or static abstract / virtual methods in classes?
- what about readonly/const local variables / parameters

this might concern the CLR but anyway:
- what about a IArithmetic interface
or even
- what about type classes (for F# )
- what about new <- declarations in interfaces WITH parameters

All these are lacking and all these hurts noadays where you try to decouple as far as possible

i've got a question,
if IEnumerable<T> is changed to IEnumberable<out T>, how can things like List<T> implement it?
List<T> does add Ts and doesnt that break the co-variance? can the interface be co-variant and the implementing class not be?
(class List<T> : IEnumerable<out T>)

im sure anders thought of this ages ago but still, it'd be interesting to hear how that fits together

-edit-
btw where can we get those cup<T> (cup of T for any non geeks out there) cups

public extends DateTime
{
    // Extension property
    public DateTime Tomorrow
    {
        get { return this.AddDays(1); }
    }

    // Extension method
    public DateTime SetTime(int hour, int min, int sec)
    {
        return new DateTime(this.Year, this.Month, this.Day, hour, min, sec);
    }

    // Static extension method
    public static int DaysBetween(DateTime startDate, DateTime endDate)
    {
        return endDate.Subtract(startDate).Days;
    }
}

Notes

• The "this" keyword represents the instance of the object the extension method/property is attached to.

Benefits

• There is no need for a dummy "this" parameter on the extension methods as with the old syntax.
• Extensibility - it would be easy to see how other extensions could be added e.g. indexers, etc.
• Keeps all your extensions for a class together.
• Clean, concise, familiar syntax without any freaky context keyword tricks.
• Other than the enclosing "extends X" everything inside the braces is normal code.
• The same rules that classes use for the "this" keyword apply to the new "extends X" construct i.e. the "this" keyword can only be used in the non-static extension methods.

Downsides

• Would make the original extension method syntax redundant

I'm going to be a heretic and flatly state that Anders is wrong about one thing, and I drank the kool-aid starting back with Turbo Pascal.

We're going to see a /parallelize switch on the compiler. It may be C# 7+, but we're going to see it. I remember the arguments against garbage collection, against dynamic typing, etc.

We will probably see 8+ cores on the user's desktop and 16+ cores on the developer's machine, and probably 16Gig, and that's enough to crunch one heck of a lot of graphs for a compiler. Most programs aren't the worst-case type of scenarios that people talk about, people still think linearly, so while I wouldn't expect the parallelize switch to work on Word or Excel, or any paint programs, I would expect it to be able to make enough use of parrallelism to make it twice as fast on a standard application as a single threaded program, even if it uses all 8+ cores to become twice as fast. It's going to be innefficient as anything, but it's still a 'free' 2x improvement in speed.

Will the /parallelize switch become anything more that a gimmic to make old programs and casual games run faster? That I don't know. That's where my crystal ball fails me. Seeing what they're doing with the task parallel library, I wouldn't be too surprised if between that and the software transactional memory that doing something like running multiple copies in parrallel and simply throwing away the unused portions (somthing like what the CPU does) may not make it possible to do a lot more with the compiler and library to parrallelize than Anders thinks is possible. We also may see more fine-grained parallelism and SIMD type stuff built into the VMs/CPUs. On the other hand, I've got a classical CS background, understand compiler design, and remember the 1K machines, not those behemoth 64K machines that Anders was talking about. I know how difficult the problem is, but it only has to be solved once.

My random 2c,
Ralph

Before letting it load the OS for first time, set the clock to 2008 november (maybe october will work too not sure).

Also use http://blogs.msdn.com/virtual_pc_guy/archive/2007/11/28/disabling-time-synchronization-under-virtual-pc-2007.aspx
to prevent sync with host clock.

.NET 4 will have new APIs for lazily and efficiently enumerate files/directories.  The new APIs return IEnumerable<T> and are meant to replace the existing APIs that return arrays.  Some more info is available in the following blog post: http://blogs.msdn.com/bclteam/archive/2008/11/04/what-s-new-in-the-bcl-in-net-4-0-justin-van-patten.aspx
I'll be blogging more about these APIs in the next couple of months, so stay tuned to the BCL team blog if you're interested in learning more.

Cheers,

Justin Van Patten
Program Manager
Microsoft, CLR

(Really a wish for LINQ) Enumerable.Empty, i.e., return an empty sequence. Silly to ask for something so trivial but it's missing! And of course it needs a nice literal...

Very nice. Thank you.

Static extension methods: A non-feature.

public enum Date { Yesterday, ... } public static DateTime Yesterday(this Date date) { var t = DateTime.Today; if (date == Date.Yesterday) t = t.AddDays(-1); ... return t; }

Besides, having yesterday be relative to a given date is more generic.

In position 02:07 in the WMV File Version you can hear how he got a new email,...ROFL

Anders and Erik for the Nobel Peace Prize

How about a post-release review for .NET 4.0? A lot of stuff has gone on through the year (notably Rx) which are terrific topics for future discussion. I think we're all interested on where C# , the BCL and .NET Framework as a whole are heading.

It's a pleasure to see the rockstars of .NET on this masterful concert. Thanks guys.

Also, in reply to Anders, I have a suggestion for the extension property notation:

public static class ExtensionProperties

{

    // The extended type appears after the colon, following the property declaration.

    // The "this" keyword refers to the extended (/indexed) object. 

    // Property.

    public static string Password : ICredential

    {

        get { return this.Password; }

        set { /*Business logic*/  this.Password = value; }

    }

    // Indexer.

    public static T this[int index] : IList<T>

    {

         get { return this.ElementAt(index);  } 

    }

}

As for extension fields (which is what'd make extension properties something of its own), some engineering on the compiler would be necessary. Simply put: we'll need to have fields on the extension class, which will be static. By natural means, said field would be shared by all objects calling the extension property. Thus, some mechanism would be required to "bind" extension fields to the instances being extended.

NOTE: The "property-hiding" scenario described was intentional. This should either hide the member or raise a compile-time error.

New property system and property extensions in C# 5.0

// A product type in this sample has a property Name of type String var product = new Product();
// This will print "Product.Name.IsDirty: False" Console.WriteLine("Product.Name.IsDirty: {0}", product.Name.IsDirty);
// Now let's try to update product's Name property product.Name = "T-Short";
// And now this will print "Product.Name.IsDirty: True" Console.WriteLine("Product.Name.IsDirty: {0}", product.Name.IsDirty);
// Then when you try to save this product in database, your Store Repository // will know for sure which fields must be saved and which can be skipped storeRepository.Add(product); storeRepository.SubmitChanges();