VB and C# enhancements in VS 2010


Choosing a programming language is a personal choice that each programmer gets to make.  It is akin to choosing a flavor of ice cream – there are many great options out there, but your favorite flavor is a matter of personal preference. 


 


In Visual Studio 2010, we’ve made several enhancements to our two most popular languages, Visual Basic and C#, to give programmers all the tools they need to build great software no matter which language they prefer.


 


Visual Basic


The Visual Basic team focused on adding productivity features to the language so developers can get more done in fewer lines of code.  The most common customer request for Visual Basic is to remove the underscore (“_”) character when breaking a code statement across multiple lines in most cases.  Visual Basic 10 introduces implicit line continuation, which removes the need for the underscore character in most cases.


 


    Function Filter(


                    ByVal customers As List(Of Customer),


                    ByVal orderCount As Integer


                   )


 


        Dim query =


                    From c In customers


          Where c.Orders.Count >


                orderCount


                    Select c


 


Another new productivity feature is auto-implemented properties.  With auto-implemented properties, lines of boiler-plate property implementation code can be replaced with simple one-line declarations.  Previously, property declarations often looked like this:


 


    Private _FavoriteFlavor As String = “Butter Pecan”


 


    Property FavoriteFlavor() As String


        Get


            Return _FavoriteFlavor


        End Get


        Set(ByVal value As String)


            _FavoriteFlavor = value


        End Set


    End Property


 


    Private _FlavorList As New List(Of Flavor)


 


    Property FlavorList() As List(Of Flavor)


        Get


            Return _FlavorList


        End Get


        Set(ByVal value As String)


            _FlavorList = value


        End Set


    End Property


 


Now property declarations can be declared much more simply:


 


    Property FavoriteFlavor As String = “Butter Pecan”


    Property FlavorList As New List(Of Flavor)


 


Collection initializers and array literals are simpler as well.  Collections can now be initialized when they’re declared, and the type of array literals is inferred by the compiler.


 


    Dim toppings = New List(Of String) From


        {


         “sprinkles”,


         “chocolate chips”,


         “strawberries”


        }


    Dim cones = {“sugar cone”, “waffle cone”} ‘the type String() is inferred


 


 


Visual Basic 10.0 now has better support for lambdas.   Lambdas can now contain expressions that don’t return a value, as the Sub keyword indicates below:


 


    Array.ForEach(toppings, Sub(n) Console.WriteLine(n))


 


Sometimes you’d like to do more complex work inside a lambda declaration.  Visual Basic 10.0 supports multiline lambdas.  The compiler will infer parameter and return types where possible just like in regular lambdas.


 


    Dim doubleDown = Function(n As String)


                         If n.StartsWith(“s”) Then


                             Return “extra “ & n


                         Else


                             Return n


                         End If


                     End Function


 


Interoperating with dynamic language code such as Python and Ruby has become simpler in Visual Basic 10.0.  For example, the following code snippet calls a method defined in a Python library “math.py”:


 


    Dim mathLib As Object = python.UseFile(“math.py”)


    Dim firstNumber = 44.2


    Dim secondNumber = 9.5


    mathLib.PowerOf(firstNumber, secondNumber)


 


 


C#


C# 4.0’s major themes are interoperability with dynamic programming paradigms and improved Office programmability.  Dynamic lookup, a new feature in C# 4.0, allows you to use and manipulate an object from IronPython, IronRuby, JScript, the HTML DOM, or a standard .NET library in the same way, no matter where it came from.  Language enhancements such as named and optional parameters and improved support for COM clients give C# developers who are working with Office APIs the same great experience that Visual Basic developers have enjoyed.


 


Adding the new dynamic keyword to your code allows its type to be resolved dynamically at runtime rather than statically at compile-time.  This allows dynamic languages to expose their objects to C# in a way that feels natural to a C# programmer:


 


    dynamic dynamicObject = GetDynamicObjectFromRuby();


    dynamicObject.Foo(7);


    dynamicObject.Property = “Property value”;


    dynamicObject[0] = “Indexed value”;


 


Optional method parameters are familiar to Visual Basic and C++ programmers and are now available for C# programmers.  Optional parameters are declared with a default value in the method signature, as follows:


 


    private void CreateNewStudent(string name, int currentCredits = 0, int year = 1)


 


The method above can be called in any of the following ways:


   


    CreateNewStudent(“Chloe”);


    CreateNewStudent(“Zoe”, 16);


    CreateNewStudent(“Joey”, 40, 2);


 


To omit the currentCredits parameter value but specify the year parameter, the new named arguments feature (highlighted) can be used.  All of the following are also valid calls:


 


    CreateNewStudent(“Jill”, year: 2);


    CreateNewStudent(name: “Bill”, currentCredits: 30, year: 2);


    CreateNewStudent(“Will”, currentCredits: 4);


 


Named arguments are also a great way to write self-documenting calls to your existing methods, even if they don’t use optional parameters.


 


Learn More


Find out more about Visual Studio 2010’s language enhancements and download samples on the VB Futures site and the C# Futures site.  To play with the new features, download and install Visual Studio Beta 1, then join the conversation.


 


Namaste! 


 

Comments (42)

  1. Andrew Webb says:

    The interesting thing re. C# dynamic is: what’s the signature of ‘GetDynamicObjectFromRuby’ ?  E.g. does it return System.Object?

  2. Andrew Webb says:

    Or is the return type of GetDynamicObjectFromRuby() marked as being ‘dynamic’ ?

  3. danieldsmith says:

    I see VB is getting auto-implemented properties.  It looks like you can actually initialise them as well, which you can’t currently do in C#, which makes auto properties in C# practically useless.

    Why isn’t this deficiency being addressed in C#?  See the following request on Connect from over a year ago:

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361647

  4. pminaev says:

    @Andrew: it doesn’t matter. Even if it returns "object", you can still assign that (or, in general, value of any other reference or boxable type) into a "dynamic" variable, after which all operations on that variable will be dynamic. Return type of GetDynamicObjectFromRuby() would make a difference when you call methods directly, i.e.:

     GetDynamicObjectFromRuby().Foo(7); // compile-time error if return type is "object", dynamic dispatch if it’s "dynamic"

    And also when you use local type inference:

     var o = GetDynamicObjectFromRuby(); // depending on the type of return value, type of o will infer as "object" or as "dynamic"

    It can also subtly affect overload resolution. But for the purpose of this example, it doesn’t really matter.

  5. James Hancock says:

    The big missing LINQ is the ability to do easy left/right outer joins. Please provide a leftjoin and rightjoin command to linq so that we don’t have to create the ugliest queries on earth to do this basic requirement!

    Pretty please!

  6. Sam says:

    Soma,

    Why have a new way of assigning values using colon?

    CreateNewStudent(name: "Bill", currentCredits: 30, year: 2);

    Why can’t we stick with equal operator?

    CreateNewStudent(name = "Bill", currentCredits = 30, year = 2);

  7. PiotrB says:

    Is there any reason to VB.NET developer to use underscore?

  8. Sam says:

    Fully agree with danieldsmith and James Hancock. Why isn’t C# getting those advantages and why is LINQ missing left/right joins? Moreover, why isn’t there a INSERT, DELETE and UPDATE statements with LINQ? For example:

    from s in MyCollection

    where s.City == "Test City"

    update s.City = "My City"

  9. Thank you for these great questions! I’ll respond to the ones related to C# language design below.

    @Daniel:

    I don’t think auto-props in C# are useless without initializers! You can initialize them from the constructor, and if you want them to be effectively readonly, you can make the setter private. I agree we could do more here. As to why we haven’t this time around: there’s so much we could do that we just can’t do it all. The strong focus on enabling better interop – dynamic through the DLR, and Office etc through the many COM-related features – has really kept us fully occupied!

    Also, I would like improvements to auto-props in the future to be more part of a package. If we can figure out how to do readonly autoprops (that work with object initializers) etc, that’d be a stronger candidate for a future update of the feature.

    @James:

    We do support left outer joins (and by symmetry, right outer joins), although slightly indirectly: group joins (as represented by the GroupJoin query operator and by the “join … in … on … equals … into …” clauses in query expressions) typically give you what you actually want. If you really need to flatten the result to a relational-style rectangular shape, call DefaultIfEmpty on each resulting collection and “from” over it:

     from c in Customers

     join p in Products on c.City equals p.City into nearbyProducts

     from p in nearbyProducts.DefaultIfEmpty

     select new { Customer = c, Product = p };

    We could have many specialized join operations but it seems better in a language to have one generalized construct – group join in this case – than many specialized ones.

    @Sam #1:

    If we could have used “=” we would! Unfortunately that syntax already means something else, and would often be ambiguous. Look at:

     CreateNewStudent(year = year+1);

    Are we passing a local variable year by name to the “year” parameter of the CreateNewStudent method, or are we  adding one to the local variable “year” and passing the result by position to the CreateNewStudent method? For backward compatibility it would have to mean the former, but whoever wrote it would probably have intended the latter.

    To avoid confusion – and the need for additional disambiguating syntax – we decided the lesser evil was to use another glyph for passing arguments by name. Now I find myself kind of wishing we had done object initializers with “:” instead of “=” :-).

    @Sam #2:

    Coming up with a provider neutral abstraction over queries was hard enough! The insert/update/delete paradigm is strongly tied to a table-based view of the world and much less universally applicable than the set of query operators we have for LINQ. If we can come up with a very general abstraction over data updating in a way that can be expressed as an API, then I am not adverse to considering language support similar to query expressions. But at this point we really truly do not know how. And baking in relational-database specific constructs to a non-relational language would be a big mistake I think.

    Thanks again,

    Mads Torgersen, C# Language PM

  10. danieldsmith says:

    Mads, regarding the dynamic features that have been added, it’s extraordinarily frustrating that this has sucked up so much time, especially since the fixation with implementing this feature has been at the expense of working on other areas that people actually want addressed.  It’s all the more frustrating seeing the amount of posts from people saying that dynamic support is a feature they expressly *don’t* want.

    Searching through Connect, I’m not seeing any significant requests or votes for adding dynamic support.  I do however see a *massive* backlog of issues which your customers are taking the time and effort to submit and vote on.

    It’s too late for the upcoming version, but for the next release after VS2010 & .NET 4, please try and be more customer focused.  At the moment it’s like the lunatics have taken over the asylum – you’re expending huge amounts of time and money implementing features people have not asked for, and don’t want, and not addressing the ones that people are actually voting for!

  11. @PiotrB:

    The design goal of "implicit line continuation" is that in the 98% case you’ll never need to type an underscore again :).  When we started designing the feature, we looked at all the places in the language where people naturally use underscores and targeted those areas first.  

    For example, here’s just some of the places where the underscore is now implicit:

    – after attributes

    – after commas

    – after assignment operators (=, :=, += etc)

    – after any binary operator (+, -, *, >, <, <>, IsNot, And, Or, Like, >>, Mod, ^ and the list goes on…)

    – after "(", "{", "<%="

    – before ")", "}", "%>"

    – before and after LINQ query operators

    We’ve found that those are the tokens that are most often followed by underscores.  Also any upgraded code that uses underscores will still compile as expected.  

    Having said that, there’s places in the language where it doesn’t really make sense to use an underscore, and we haven’t removed them there.  For example:

    Function _

       MyMethod() As Integer

    Technically we could enable implicit LC after "Function", but typically people don’t format their code that way.  In this case you would still need to use an underscore.

    Hope that helps, please try it out in Beta1 and send us your feedback!

    Thanks,

    Jonathan Aneja, VB Compiler PM

  12. James Hancock says:

    I rest my case about truely ugly syntax that is almost impossible to memorize so I have ot look it up every single time :) The concept of left and right joins are simple and required and obvious and supported by all databases. Return value, but if null, return null for values. Lots of sense and should be simple with leftjoin, rightjoin. Syntaxically you could just have optionaljoin and make sure that it’s left to right, but I don’t think it would be as obvious.

    My point is that the syntax is ulgy and difficult and that is part of what makes linq nice, obvious and simple queries. Try debugging that mess above when there are 15 of them in one query and you’ll understand the problem.

  13. Sam says:

    @Mads Torgersen: So, if its hard, you won’t do it? :-)

    I think the "Update" and "Delete" feature needs to be tied closely to the regualr programmer’s view of the world too! It is a very useful feature. Look at this simple problem for example:

    Imagine that we have to update a property for some employees in a collection that meets some condition. This is one way how we do it today:

    var emp = from e in EmployeeCollection

             where e.Salary > 100000

             select e;

    foreach(Employee ee in emp) // or emp.ToList()

    {

       ee.Bonus = 100;

    }

    With the easy "Update" feature that I requested before this would be reduced to:

    var emp = from e in EmployeeCollection

             where e.Salary > 100000

             update e.Bonus = 100;

    More efficient, elegant and easy to read. Aren’t those 3 big enough reasons to try and get that to .NET developers?

    My example is really simple, imagine the more interesting cases that can be simplified! This also helps presentation technologies like Silverlight and WPF as well in data-binding scenarios.

  14. @James:

    In our view, left joins exist because of the limitations of a flat table based model like SQL’s. You want each of the left elements paired with a list of the right elements that they join with. This is hierarchical; list within lists (or sets within sets) and tables can’t express that, so left outer joins are the best approximation.

    In an object-oriented programming language we don’t have the same restriction on the shape of the result. Group join gives you the structure you really want.

    The "ugly" (is it that ugly?) example I wrote was to illustrate that you can get left join semantics if you really want to (for instance if you need to subsequently pour it into a flat table), but the overall point is you don’t often want to.

    Yes it is a different perspective, yes it takes a bit of getting used to. But once you get there, you will never miss your left joins again.

  15. @Sam:

    No as a matter of principle we don’t do difficult stuff :-).

    Seriously, once the examples you want to improve get more complicated, so does the solution. I won’t go into details here, just mention one of many complicating factors: transactions.

    No-one has succeeded in coming up with an abstraction of the update features that is a general as LINQ, and it is not for lack of trying. We may get there.

  16. @Daniel:

    You bring up the subject of how we decide what to put in the languages, so let me say a little bit about how we approach programming language design.

    Our goal is to have programming languages that are good to use, remain relevant in the face of emerging needs in the developer community, and live for a long time. We can only evolve the languages at a certain pace before a) learning the next version becomes too much of a jump, and b) the language “fills up” to quickly and becomes unwieldy as a whole.

    As a consequence we have a very tight “budget” at every release – and over the whole lifetime of the language – for how much we can add. Anders Hejlsberg usually says that “every feature starts with minus a thousand points.” In other words, it is not enough for a feature to be good and useful to get into VB and C#; there are easily enough good and useful features in the world to fill up a hundred programming languages to the brim.

    So we need a very judicious approach to choosing. We strive to maximize both the tactic and strategic value, so that what we add will have a huge positive impact on current scenarios, as well as being a great and durable addition for the long term. We have to make sure that a feature – or set of features – is principled and general, and meshes well with the existing language, as well as with other developments on the platform. We also need to exercise a careful balance between being reactive (responding to existing customer needs) and proactive (providing new opportunities to customers).

    All of this is far from an exact science. We inform these decisions through massive and multi-faceted interactions with customers, through Connect (yes we do read and evaluate every single suggestion), blogs, conferences, online forums, MVP programs, etc. And once we understand the problems that we want to try to solve, we expend enormous effort on the team and across the company on innovation to find the most effective, simple, general, efficient and elegant solutions.

    Now let’s look at C# 4.0. Two of the most frequently and urgently expressed customer pain points are:

    a) Office programming (and other COM interop) is extremely ungratifying in C#, and

    b) VB and C# differ in arbitrary, important and frustrating ways.

    On top of this, a huge new opportunity is opening up:

    c) The addition of dynamic programming languages on .NET, and in particular a wonderful implementation platform, the DLR (Dynamic Language Runtime), which provides for efficient cross-language dynamic dispatch of operations with a generality and usability that we believe is truly game changing.

    From this situation come our top priorities: Fix parity with VB, fix Office programming, and facilitate smooth dynamic interop. The two former points are more backward looking – fix existing problems. The third is forward-looking, and will have to prove its worth in the years to come. No platform has ever offered this degree of tight, safe and efficient integration between static and dynamic worlds – we are breaking new ground here. We think and hope that this will have a huge impact in the future, will eventually be imitated by competitors and will in the long run come to be seen as the first and defining strong bridge across that decades-old and utterly confounding gulf between the separate worlds of static and dynamic systems.

    The dynamic feature has been reviewed extensively by customers, and has in fact changed dramatically over the time of its design as a direct result of customer feedback on the very early ideas we shared. We have strong evidence from customers already that we are right to do dynamic and we are doing dynamic right.

    So much for how we set the course for C# 4.0. What does the future hold? We will continue to look at what customers are struggling with. We will continue to evaluate and be inspired by the hundreds of suggestions on connect, most of which, by simple but heart-wrenching arithmetic, will never get into the language. We will try to remove the biggest stones in the road already travelled, while also building great bridges to new lands.

    Now keep that feedback coming!

    Mads

  17. PiotrB says:

    @Jonathan Aneja:

    "

    Function _

      MyMethod() As Integer

    Technically we could enable implicit LC after "Function", but typically people don’t format their code that way.  In this case you would still need to use an underscore.

    "

    I thought that’s is technically possible to enable implicit LC, it’s a source of my question.

    Have you any list of cases where we _must_ use explicit underscore for LC.

    "

    Hope that helps, please try it out in Beta1 and send us your feedback!

    "

    Thank you very much for this exhaustive answer. Implicit underscore is one of most expected feature of VB.NET 2010

  18. Sam says:

    @Mads Torgersen: If the C#/.NET teams at Microsoft can achieve this, I want to present them the Turing award! :-)

    Keep up the good work, although I think .NET 5 will be much more interesting thanks to Anders Hejlsberg’s video on future of languages.

  19. James Hancock says:

    Your arguments about left/right join don’t make sense.

    If I’m using EF and I choose not to create a direct object and instead just leave the reference, or you have a reference that applies to multiple tables and EF can’t handle it because they left out that functionality, you will definately need left/right outerjoin support because our way is messy and impossible to try and maintain when you’re talking about dozens of tabes that may be left joined.

    The same is true of objects.

    If I have two objects that referenc eachother based on a key, but I want to return all of the items in the first, and the second if there is a match, but give me the first even if there isn’t a second that matches, you could either do it your way, which works,but is a mess, or you could do my way:

    from o in object1 leftjoin c in object2 on o.ID = c.ID where blahblah blah.

    My way is incremental, and clear what’s related to what, and obvious what it’s doing. Yor way creates new fake objects/tables and then handles it with the unrelated reference that is impossile to figure out which is which without having to carefully read every part of the query over an over again.

    Sorry, but your argument doesn’t hold water. This always happens, even in the object world and we don’t need to make it more difficult, not less.

  20. tye says:

    On the ‘join’ paradigm shift, linq v. t-sql, why not call it ‘groupWith’ and leave it at that? Why call it a ‘join’ if the t-sql spec calls it ‘join’, ’cause this leads the old-jacks, like myself, a bit bewildered when attempting to sort thru the cascading appendages being laid on C#, ad nauseum.

    If ‘group’ means it’s heirarchical, why not document it as such and we can still have the best of old and new approaches of spanning object access via table/object-linking.

    Or how’s this, call it ‘linqTo’ to distinguish it from a ‘join’.

    The more cryptic c# becomes, the more likely it will grow wildly into a beast too brazen to burden ourselves with. Can we keep it "fool proof," for old geezers like me I mean :), please?

  21. Konsstantin says:

    @Mads to Sam #2:

    [Coming up with a provider neutral abstraction over queries was hard enough! The insert/update/delete paradigm is strongly tied to a table-based view of the world and much less universally applicable than the set of query operators we have for LINQ.]

    Mads,

    can you please provide an example where UPDATE in LINQ does not make sense?

    Sure, there will be an issue with database query from multiple tables, but you can specify which table you would like to be updated.

    You can update XML, can you?

    Other LINQ targets should be less complicate, or I’m missing somthing?

    Please give me some examples where UPDATE in LINQ would not make sense even though object is updatable (not read only)

    I do not see why UPDATE is relational database-specific operation. Properies, as well as collection and array member values are get updated too.

    BTW, having DELETE in LINQ would be sweet too!

  22. Colin Meek says:

    @James Hancock

    In .NET 4.0, the Entity Framework recognizes various LINQ outer join patterns. As Mads suggests, you will need to use group joins and structured result types in 3.5 SP1 however.

  23. @James:

    I don’t know the Entity Framework well enough to be able to speak to what it supports or not, sorry.

    I think we are talking about slightly different kinds of examples, which may be why I don’t make sense to you . The difference, I think, is that I am talking about many-to-many relationships and you are talking about one-to-one. So let me address both kinds here.

    Many-to-many first: the question I want to answer in my example is this:

    “For each customer, which products are produced in their home city?”

    I can ask the question like this:

    from c in Customers

    join p in Products on c.City equals p.City into ps

    select new { Customer = c, Products = ps }

    What do you get back? the customers, paired with the list of products produced where they live. In other words:

    “For each customer the products that are produced in their home city.”

    Compare with the original question above! It doesn’t get more natural than that!

    Now, your scenario seems to involve a one-to-one relationship, where the second “one” is optional, i.e. zero/one. You want to pull these strongly coupled objects together based on a shared key.

    This doesn’t often happen in practice in an object-oriented model, or one that is modeled through an object-relational (O/R) framework (such as EF or LINQ to SQL), because the relationship would typically already be represented more directly by an object reference one or both ways, or even by an inheritance relationship. So having a primitive operator specifically for the purpose of this case doesn’t seem right. In general, the foremost task of an O/R framework is to hide key-based relationships behind more direct representations.

    But say that you don’t have that structure already; maybe you are in fact out to establish it with the query. Clearly the output of a left join would give you the right kind of result here (one row per left element, with a right element or nothing attached to it), but only because you happen to know that the relationship is one-to-one. How would you do it in LINQ?

    There are multiple options (e.g. using nested queries), but the one I like best still uses the group join. Here is an example to illustrate. Say that you are representing Employees. Some of these are Partners and have extra data associated with them. In an object-oriented modeling you would have Partner derive from Employee, or at least Employees would have a nullable PartnerInfo property on them, but say that we don’t have that luxury: The model we are presented with keeps them separate, correlating by an ID key.

    Now to get all the Employee/Partner relationships I can write:

    from e in Employees

    join p in Partners on e.ID equals p.ID into ps

    let p = ps.SingleOrDefault() // throw if there is more than one partner info for an employee

    select new { Employee = e, PartnerInfo = p } // or whatever projection you wish to make

    In words: “for each employee, give me the single associated partner info, if available.”

    Another approach would be to model the PartnerInfo reference yourself through an extension method:

    public static class EmployeeHelpers {

     public static Partner GetPartnerInfo(this Employee employee) {

       return Partners.Where(p => p.ID == employee.ID).SingleOrDefault();

     }

    }

    Now you can walk up to an employee e and say

    var p = e.GetPartnerInfo();

    Compare these two approaches: both get collections of partner infos for each employee, and call SingleOrDefault on them to get null in the absence of a partner info and an exception (a good thing) if there are too many. They get those collections in different ways; one by group joining and one with a “where” query, but the “SingleOrDefault” logic applies equally to both; it is not strongly tied to the joining as it would have been with a leftjoin operation. We compose primitive operations instead of hardcoding complex ones.

    Granted it makes things more different from SQL. But we’re in a full scale programming language here; we have the ability to compose primitives, to abstract over those compositions, and to represent data with deep structures. Shouldn’t we take advantage of that?

    Mads

  24. @tye:

    Naming the LINQ operators was a delicate balance: allude to the SQL keywords to keep the intuition, but still introduce a new, object-oriented mindset. I still don’t know what is the lesser evil: risk confusion, or risk alienation :-)

    In practice I find that LINQ takes a bit of getting used to regardless of what camp you come from, but that the flexibility of the model really grows on you once you are beyond the learning curve.

    I can see how the similarity-yet-difference to SQL of some of the LINQ constructs can actively hinder mastery in some cases – that point is well taken. I recommend attacking LINQ with a good book and an open mind.

  25. @ Konsstantin:

    Looking at it again I think I may have replied to a slightly bigger question that what was asked. I do actually think that the update feature makes sense. In fact we already discussed a slightly more general feature (but haven’t decided to do it) where you can say “do { … }” at the end of a query and have that manipulate any of the objects in scope using the full arsenal of C#’s statement language.

    The main issue here is the deferred execution of LINQ queries. Once you have side effects – as you would with an update clause – you have to choose between “going eager” (running the query right now and applying the side effects) or “going crazy” (applying the side effects later when the query is actually run, and possibly multiple times – leading to totally unpredictable results).

    For this reason I kind of like the explicitness of having to foreach to do updates. However, if the update clause can only come at the end of the query (like select or group by today) and the result is void (so it is explicitly non-composable) then it might be different enough to trigger the right “eager” neurons in the reader. Compared to nested foreach loops etc. I can definitely see value here.

    I think we will consider something like this for the future, though needless to say there’s no promises one way or the other.

  26. Sam says:

    @Mads Torgersen: In the mean time, would it make sense to abstract out the "foreach" part that does the "Update" in my earlier example into LINQ? In other words, provide "Update" in LINQ – but in the background the runtime can do what the foreach does. At least make it available for updating simple properties of objects. I don’t understand how/why this is not do-able today.

    Btw, your reply to Konsstantin is using way too much abstracted language – an unnecessary evil? 😉

  27. @Sam:

    Sorry, occupational hazard :-).

    To summarize/clarify …

    On update in LINQ queries: we could add that in a future release, as a syntactic convenience. I don’t know if we will.

    On a general LINQ-like framework for modifying data: we don’t have a good way of doing it or a strong customer ask for it, so that is not in the cards.

  28. Ron Garrett says:

    And still no real support for pointers.I’m going to push this barrow as far as I can. MS staff keep telling me there is no demand!! Yet the web has plenty of moans and attempted workarounds using marshalling in C#

    Pointers – GetThem, SetThem, SecureThem

    This thread must almost be out of date. But presumably someone will still read a new posting. Also, since beta1 is already out you can only react now to bugs rather than bad design. Nevertheless I must express my extreme dismay at the abysmal treatment of VB pointers. They are the crux to any inventive programming.

    There are three needs for effective use of pointers: GetThem, somewhere to SetThem and somewhere to safely retain them. In VB5 I had all three for some needs (arrays, user types and some other structures) and used classes with static objects when needed. I bought VS2005 and threw it out!!

    I cannot for the life of me understand WHY MS should be so irresponsible. With the bragging of a CRL why the devil is it that C++, C#, J# and VB do not yet have a common access to the same language elements. As someone said "We should all be playing in the same sandpit." The trouble is that we all have too little power, and too little voice. Too few alternatives. I explored Delphi and C++ with CodeGear and found it wanting. As a consequence we ordinary folk spend our nights playing with ourselves instead of trying to change things. And that leaves you MS guys free to play with yourselves. Thats all well and good and private but wasteful. But when you in MS start playing with ME I get offended.

    For all our sakes, please give ALL OF US stable methods and common syntax to GetThem. You’ve got access to Them!

    For all our sakes, please give ALL OF US stable structures with common properties at which to SetThem.

    For all our sakes; please for ALL OF US, if you have to change a structure INCLUDE the old structure as a field within the new.

    NO – I WILL NOT BE BUYING VS2010 for the same reasons I did not buy VS2008 and THREW OUT VS2005. I’ll get by with VB5 and ASM for the difficult bits (After all, thats where I (now 72) had to start).

    Why do I hang on to VB? Its the only worthwhile language that properly defines its code loops. IF..ELSE..ENDIF; Do..WHILE etc compared with a forest of {..} in C, C++, C# and j#. Only FORTRAN defines loops more definitively. DO 100.. ..100 CONTINUE. Even PASCAL (DELPHI) uses END; but only sometimes and too often. Why is that important? It leads to easy, faster and accurate reading and so less confusion in ‘over the page(s)’ code ‘blocks’, fewer coding errors and faster coding. It has been worth the price in the past, but with poor backward compatibility it is not worth the cost of continued upgrading.

    But now it looks as though I’ll not be incurring that expense until at least 2013, if then.

    Well, did anyone important get this message? Perhaps I should expand this more and send it to the shareholders

  29. Sam says:

    @Ron: VB5, Pascal, Fortran and Delphi have something in commmon – almost no practical use or significance in the industry today. Pascal was once a good candidate to teach programming (for beginners).

    I don’t think VB5 or Fortran code is readable or easy to maintain for modern day large applications. Pointers have faded away in recent times for popular languages like VB.NET and C# (C# does support limited features of pointers in unsafe mode). Don’t see that as a feature everyone would use. The beauty of these languages is simplicity and managed code. Pointers are nightmare to debug, read and wreck havoc if not used properly. Why don’t you use C++ if you are so fond of pointers? What is it that you are trying to achieve/accomplish with pointers anyway?

  30. vijay says:

    MSDN seems to have uniformly poor documentation now.

    contrast this with about 3 years ago when all the win32 SDK stuff you would find was really well documented and excellent with proper listing of error values, sample code for each api and so on.

    Now, you dont even have proper explanation or listing of errors/exceptions for gcnew or how you would define a delegate function System::Action<T> or System::Predicate<T> for the ForEach function of collection classes and the list just goes on and on.

    Its not an isolated case and the whole thing is poor quality.

  31. richard_deeming says:

    The VS2010 page [1] says "Make sure your MSDN Premium subscription is current, and you’ll get Visual Studio 2010 at no additional cost."

    Is this a mistake, or does this mean that MSDN Professional subscribers will not get Visual Studio 2010 Professional, or will have to pay extra for it?

    [1] http://www.microsoft.com/visualstudio/en-us/products/2010/default.mspx

  32. wekempf says:

    @Daniel, so you look at connect and determine "no one" wants dynamic, huh? What did you use as a query? Did you look for COM interop? Dynamic language interop? Simplified reflection? I’m not going to bother looking, because even if there is no results, this still proves nothing. Connect is mostly used for reporting bugs, not for making feature requests, and even then there are far more reports made through different channels.  Connect is a very small, VERY SMALL part of the communication made between Microsoft and customers. Maybe YOU don’t want dynamic… and I know there’s a crowd of folks who don’t (mostly for misguided reasons), but there’s also a huge number of us that are saying "it’s about darn time". Dynamic simplifies a lot of things that we do on a daily basis, and it’s more than welcome in C#.

  33. Jono Wells {Microsoft - Visual Studio Team] says:

    Richard Deeming asked this morning if there was a typo on the Visual Studio 2010 page regarding Visual Studio 2010 availability in MSDN Professional. Yes this was in fact a typo. Active MSDN Professional or Premium subscribers (at the time of Visual Studio 2010 receive) will receive Visual Studio 2010.

    Thanks for pointing this out Richard.

    Jono Wells

    Senior Product Manager – Visual Studio

  34. Ron Garrett says:

    Sam, let’s face it. C++ as become a brilliant dog’s dinner. Even the texts warn one.

    VB (and C#) haven’t used pointers because for the last 9 years they have not been able to. I’m not worried about managed/unmanaged code. I can always build a class on a static object.

    I need access just to the addresses of an object and its data and a structure to put them into. Especially arrays. I can then point 1d, 2d, …nd arrays to the same data. Even in graphics data is nowadays 80Mb or more per image. Lockbits is a farce in that situation.

    and co-ordinating file and buffer reading is so much easier with pointers. They have never been hard to use in these ways. I see no reason to complain that they are not suitable for a "simple" language. So often, C++ would be like using a missile to kill a crow.

    I talk to my computer. I have not yet let it talk back. It might win too often. But I look forward to the day when I can program that way. Then I hope the conversation will be like Dillon and Andromeda rather than like the Atreides guru in Dune and his computer.

    Regards anyway,

    Ron

  35. Sam says:

    Ron, the audience for C# are usually not system or low-level programmers. Most of the methods, properties and features provided by the .NET Framework can easily help developers achieve the same end goal without having to deal with messy pointers. Why would one want to deal with pointers if .NET provides really easy (easier than pointers) to use classes for File handling and representing data structures? One cannot go wrong with this approach vs. pointers for almost all requirements. Pointers also compromise readability of code.

    As powerful as pointers may be, users of these programming languages don’t care much about pointers  as long as the business goals are met without having to worry about debugging, memory issues, core dump exceptions and fatal errors!

    Andres Hejlsberg can give you more insight! :)

    Good luck!

  36. MSFT PM says:

    Wake up people, these enhancements are put it to try to convince internal departments at Microsoft to embrace this technology. The office and Windows 7 teams at Microsoft will not touch the majority of this new technology like WPF and there are good reasons for it. It is too clunky to use and they have their own libraries/stacks that are stable and work much better. The sooner everyone realizes Microsoft caresless about your requests and what is needed in the field the better. Microsoft is changing paradigms faster then Obama is spending money and none of the new paradigms are any good. Quit wasting your time on these blogs and do something productive like code and make money. If you are smart you will still be using Visual Studio 2005 and quit being free beta testers for Microsoft.

  37. Thanks. It was really worth information..

  38. Levy says:

    Please add exception filters to C#. It works in VB so it should work in C# also. I really miss that feature, and I’m confident that I’m not alone in this…

  39. Marzena Makuta says:

    Hi Vijay,

    My name is Marzena Makuta and I manage the Visual C++ documentation team. We own one of the topics you refer to, gcnew, and also anything that appears under the Visual C++ node in MSDN. Our team is very interested in making sure our customers find all the information that they need.  I’d like to get some more information from you to better understand what additional content you were looking for in this topic.

    Similarly, I am very interested in hearing specifics about what you would like to see in our other topics that you would find more helpful. Please feel free to email me at marzenam@microsoft.com, and I’ll be happy to hear how we can improve.

    Cheers,

    Marzena

  40. alwin says:

    What is wrong with

    var employeesToGiveBonus = from e in EmployeeCollection

         where e.Salary > 100000

         select e;

    session.Update(employeesToGiveBonus, e => e.Bonus = 100);

    (Where session is something specific to the tech that also provides the LINQ provider, for example, NHibernate ISession.)

    This way each LINQ provider can choose what to support or not. For many LINQ providers update or delete doesn’t make sense.

    I think LIN*Q* should be kept Query only, and not be tied down to database specific scenarios.

  41. valli says:

    hi,

    its interesting to see the new enhancements of vb and c# in vs 2010. if you want more on this have a look at this link.

    http://www.vs-2010.com/vs2010/post/vs-2010-overview-vb-and-csharp-language.aspx

  42. rahul says:

    First of all. Thanks very much for your useful post.

    I just came across your blog and wanted to drop you a note telling you how impressed I was with the

    information you have posted here.

    Please let me introduce you some info related to this post and I hope that it is useful for community.

    There is a good C# resource site, Have alook

    http://CSharpTalk.com

    Thanks again

    Rahul