C# Language and Compiler Team Chat, May 7, 2007
Chat Topic: C# Team Chat
Date: Monday, May 07, 2007
Unique Users: 112
Questions Submitted: 61
Charlie Calvert-MSFT (Moderator):
Welcome to the C# compiler chat. I'm Charlie Calvert, the C# Community PM.
Charlie Calvert-MSFT (Moderator):
We have the PM's who design the compiler and a number of the key developers on the team online with us today. If you have questions about the C# language, about LINQ and especially LINQ to Objects, then you have come to right place. Any general questions about the language and the compiler are also welcome. Of course C# 3.0 questions and Orcas Beta 1 questions are particularly welcome. Go ahead and enter questions, the team is here to answer them.
Charlie Calvert-MSFT (Moderator):
Please go ahead and start entering your questions and we will get started answering them.
Mads Torgersen[MSFT] (Expert):
HI I'm Mads Torgersen, PM for the C# language and the core LINQ libraries. I'm the piñata here, blame me for design deficiencies in C# and core LINQ!
Charlie Calvert-MSFT (Moderator):
Remember that this is a technical chat, and we need to keep all questions and chatter on topic. Thank you!
Kevin Pilch-Bisson [MSFT] (Expert):
Hi Everyone. My name is Kevin Pilch-Bisson. I'm a dev on the C# language service (IntelliSense and stuff), but I poke around in the compiler from time to time...
Yuval [MSFT] (Expert):
Hello all. I'm Yuval - a tester on the C# Compiler Team. I'm looking forward to answering your questions.
Luke Hoban [MSFT] (Expert):
Hi - my name is Luke Hoban, and I'm a Program Manager on the C# Compiler. I’m looking forward to answering any questions you may have. After the chat, you can get hold of me on my blog at https://blogs.msdn.com/lukeh.
MarceloGuerra - MSFT (Expert):
Hi, I'm Marcelo Guerra, I'm a tester in the C# compiler.
Eric Lippert-MSFT (Expert):
Good morning everyone, I am Eric Lippert, a developer on the C# compiler team. My principle areas of expertise are the semantic analysis of lambdas and type inference, but I'll answer questions about anything. :)
Mads Torgersen [MSFT] (Expert):
Q: is there a reason why parameterized threads can only take one argument? I find it a bit annoying to have to create specialized classes just to pass arguments to a thread.
A: You often find yourself wanting to wrap up several values as one object - on the fly. We address some of those situations with anonymous types in C# 3.0, but for others, like yours, they don't really cut it. We are looking at this for C# 4.0. Maybe tuple types are a way to go. Of course, no promises here!
Mads Torgersen[MSFT] (Expert):
Q: Can someone comment on future C#-specific add parallel processing functionality/syntax?
A: As multicores get more and more cores, and more and more uptake, this is really the wakeup call for the software community to get parallel programming right. We are working on a bunch of stuff, but I shouldn't go into details. Expect a version where you see better library support, before you see new actual language features.
Eric Lippert-MSFT (Expert):
Q: Any thought off adding any new runtime type operators in the future to C#, such as a GetMember() which would return a MemberInfo for a named member of a class/struct...this would aid in Mock Object tools and other areas...
A: I personally would love to have a memberinfoof operator that worked like the typeof operator. I basically had to implement all the guts of it in order to make expression trees work, because an expression tree such as ()=>M() has its body translated into basically Call(memberinfoof(M)).
Luke Hoban [MSFT] (Expert):
Q: What kind of feature can we expect for C# 4.0? Things from Spec# for instance?
A: Contracts and non-nullable types are discussed in the language design meetings as possible features for a future version of C# - but there are no concrete plans yet. What do you think? Are these features you'd like to see in C#?
Eric Lippert-MSFT (Expert):
Q: Any thought off adding any new runtime type operators in the future to C#, such as a getmember() which would return a MemberInfo for a named member of a class/struct...this would aid in Mock Object tools and other areas...
A: However, actually coming up with a good syntax for the operator is pretty tricky. Evaluating the name of a type doesn't have any side effects, but to get MemberInfo working you need to know not just the types of all of the arguments, but actually the expressions in the arguments too in some circumstances, in order to get type inference working.
Mads Torgersen[MSFT] (Expert):
Q: LINQ question: Are there any plans to integrate Regular Expression syntax into the expression processing? Or are Lambda expressions/ anonymous methods containing the regex the true way to go? Or am I missing something?
A: I think regular expressions and expression trees are two different things. Regular expressions are about matching strings, and expression trees are about representing code-at-runtime, i.e., after it has been parsed from strings. I suppose you could combine those to create expression trees from some custom language that you parse using regexs, but they are not naturally related technologies.
Eric Lippert-MSFT (Expert):
Q: Any thought off adding any new runtime type operators in the future to C#, such as a getmember() which would return a MemberInfo for a named member of a class/struct...this would aid in Mock Object tools and other areas...
A: So, yeah, this is a frequently requested feature and I would like to see it happen. It certainly will not happen in C# 3.0, but I am holding out hope for 4.0. In the meanwhile you can mock up your own by using expression trees and extracting the MethodInfo from the call node!
Mads Torgersen[MSFT] (Expert):
Q: @Mads: I don't mind detail :-) Something link OpenMP or are you avoiding stuff like that?
A: Peter, it is not for your sake that I am avoiding details at this point :-)
Mads Torgersen[MSFT] (Expert):
Q: Currently the Regular Expression object regex, the internals cannot handle the thread.abort message gracefully...any chance that could or has been added to Orcas or the future?
A: I am sorry but I don't know the details of the plans in this area - I don't think anybody on this topic can help you there.
Eric Lippert-MSFT (Expert):
Q: Follow-up: I would use syntax like memberof(MyClass::MyMethod) which would return the MI for the MyMethod method of the MyClass class...just a thought...:)
A: Sure, but what if there are ten overloads and some of them are generic and require type inference? Just getting the most basic case working would be trivial. But the real power of the operator comes into force when it can use the entire mechanism of C# overload resolution and type inference to figure out which MethodInfo is the best one of all the possibilities.
Charlie Calvert-MSFT (Moderator):
We have lots of great experts here who know the language, so please feel free to provide us with plenty of questions. Expert questions, beginning level questions, just ordinary questions, we are interested in all types of questions!
Mads Torgersen[MSFT] (Expert):
Q: RE: Spec#: are you leaning more towards just Spec# or are you including other similar tools like nContract?
A: We are definitely interested in the spec# work, both the contracts and the non-nullable reference types. It still remains to be seen whether we can find a way to massage these concepts into the existing framework, but we are certainly going to look at it, possibly for the next version after Orcas. If you want it, keep asking for it!
Mads Torgersen[MSFT] (Expert):
Q: @Mads: RE Detail: I know, I was just hoping ;-)
A: No harm in trying... :-)
Eric Lippert-MSFT (Expert):
Many members of the compiler team have blogs.
Eric Lippert-MSFT (Expert):
I'll post some links.
Eric Lippert-MSFT (Expert):
https://blogs.msdn.com/ericlippert/, https://blogs.msdn.com/sreekarc/, https://blogs.msdn.com/peterhal/, https://blogs.msdn.com/charlie/, https://blogs.msdn.com/wesdyer
Mads Torgersen[MSFT] (Expert):
Q: Since automatic properties should have both setter and getter methods, why not make them even more concise?
A: I'm guessing you’re looking for "int X {}" or something like that? Two reasons: 1) readability - we feel it can get too brief for easy recognition, but the more important is 2) we may want to find ways to do get-only auto-properties in post-Orcas versions.
Luke Hoban [MSFT] (Expert):
BTW - How many folks have downloaded Orcas Beta1? Any comments/issues/thoughts/feedback?
Keith Farmer [MSFT] (Expert):
Q: What about the data access patterns? Are they going to be rewritten for LINQ to SQL?
A: I'm not sure they'll necessarily be rewritten because of LINQ to SQL. LINQ to SQL is another means of performing your query, but it doesn't really deviate in-the-large from what people have been doing all along with hand-coded data access layers. What it does change is the level of boiler-plate developers have to write. In general, though, I think the new language features in VB and C# will make some new, useful patterns more tractable, and that idea is compelling.
Charlie Calvert-MSFT (Moderator):
Q: I enjoy reading blogs that get in to the nitty gritty, low level details of design and implementation as well as the gotchas that creep up after the fact (such as Raymond Chen's). Do any of the experts have blogs like this? Links?
A: Eric Lippert has a great and very active blog: https://blogs.msdn.com/ericlippert/. Luke has been posting recently: https://blogs.msdn.com/lukeh/ Wes Dyer, who should be joining us soon has a fabulous blog: https://blogs.msdn.com/wesdyer/. Jomo is another one with some great recent articles on LINQ: https://blogs.msdn.com/jomo_fisher/default.aspx. Sree is just starting his blog, but he has been doing great things: https://blogs.msdn.com/sreekarc/. In general, read my Community Convergence posts to keep up with C# team bloggers: https://blogs.msdn.com/charlie/archive/tags/Community+Convergence/default.aspx.
Mads Torgersen[MSFT] (Expert):
Q: I wouldn't mind hearing about some of the themes you think are most important for C# and LINQ to pursue in the post-Orcas timeframe - we are in the middle of prioritizing our efforts here, and we value your input.
Eric Lippert-MSFT (Expert):
Q: Is the current plan to continue extending C# indefinitely? I at least am already finding it challenging keeping up and learning all the new features and interactions between them as they appear.
A: I am finding it challenging too! If you think it’s hard to keep up with learning the interactions between all the features, try designing and implementing those interactions some time. :-) But seriously now. Yes, we want to keep on growing the C# language and innovating in this space, but we do not want to do innovation for its own sake. Language features like LINQ are always targeted at specific needs that we've identified through doing research -- research which includes doing chats like this, by the way. For LINQ we realized that lots of people are doing lots of stuff with lots of data, and that there are potentially big wins in moving the semantics of sorting, searching, grouping and joining out of the object models and into the language. I think however that it is reasonable to expect that the diff between C# 3.0 and C# 4.0 _as a language_ will be smaller than the diff between 1.0 and 2.0 (generics, nullables, anonymous methods) and 2.0 to 3.0 (lambdas, queries, extension methods, etc.)
Luke Hoban [MSFT] (Expert):
Q: On the order clause of a query expression there are options for ascending and descending. Is there an option for reverse order? Could there be one? It would be useful for traversing arrays or collections in back order.
A: There is a .Reverse() extension method which you can use - but there is not any special C# syntax for this.
Mads Torgersen[MSFT] (Expert):
Q: C++ has pointers to functions, C# has delegates, the difference *in my mind* is one has to new up the delegate in C# where in C++ one did not have to do that to access functionality within the current object. Open thoughts?
A: I must admit that I sometimes bemoan the fact that we made delegates so complex - a nice simple "just make a reference" kind of approach would have been smoother. No helping that now, but at least from C# 2.0 onwards you don't have to explicitly new up the delegate, you can just cast the method group (or anonymous method or lambda expression) to the right delegate type. Also in .NET 3.5 (Orcas) we are introducing "standard" delegate types Action<...> for void-returning and Func<...> for value-returning delegates with arguments from 0 to 4.
Charlie Calvert-MSFT (Moderator):
Q: I enjoy reading blogs that get in to the nitty gritty, low level details of design and implementation as well as the gotchas that creep up after the fact (such as Raymond Chen's). Do any of the experts have blogs like this? Links?
A: I should also mention that Mads, when we can get him to post :), has fantastic insights into the C#, LINQ, and the directions the language might take in the future: https://blogs.msdn.com/madst/
Luke Hoban [MSFT] (Expert):
Q: LH: I downloaded and played a little bit with Orcas Beta 1. Not too much time thought
A: Great - feel free to send us feedback once you get a chance to use it. You can email me at lukeh@microsoft.com with any thoughts.
Mads Torgersen[MSFT] (Expert):
Q: To further "Theory’s” question... have you looked at other ways of extending the language instead of continually adding new syntax? Perhaps opening the compiler to custom "add-ins" that would manage their own syntax snippets?
A: We've talked about this a lot of times. Opening up the language too widely is dangerous because it effectively creates myriads of dialects meaning that people are not *really* coding in the same language. The trick is to find the right balance where it still feels like your programming, not metaprogramming. We have no concrete plans.
Mads Torgersen[MSFT] (Expert):
Q: On the same line as the questions about C# and features, is there a point in the future when the C# team will decide that the language is complete?
A: I don't think so. It is likely that there will be some extended period of time where we don't feel that there are ways to address important everyday customer needs by extending the language and so won't, but we'll reserve the right to come back and make it better at any point in time - there'll be no "complete forever" date, only "complete for now" dates :-)
Charlie Calvert-MSFT (Moderator):
Okay, we are coming up on the halfway point and I'm concerned that we aren't taking sufficient advantage of all this amazing talent. If you have questions about expressions trees, generics, lambdas, extension methods, query expressions, query operators, then this is a good time to ask. This is also a great time to ask questions about language basics, and about the reason the language has taken a particular shape.
KevinPi [MSFT] (Expert):
Hey everybody, I need to leave a bit early, but thanks for coming!
Charlie Calvert-MSFT (Moderator):
Q: is there going to be any steps towards simplifying cross thread calls to GUI objects? It’s not hard to do, using methodinvokers and such, but it does seem like a lot of typing.
A: Sorry, it doesn't look like anyone here knows the answer to this one, or at least has anything else to add. It's a reasonable question though, so this might be a question you can take up on the forums.
Eric Lippert-MSFT (Expert):
Q: Java is coming up to version 1.7/8...C# is coming up to 3.5 ...general thoughts on that? Where does C# excel vs. Java and vice versa?
A: It is important also to note that there are differences between C#-the-language vs. Java-the-language and the CLR vs. the JVM. In the latter area, I would point at things like the deep runtime support for efficient generic types that the CLR has and the JVM lacks. In the former area, I'd point at things like all the LINQ features, anonymous methods, nullable types, etc. And I note that the Java guys have backpedalled somewhat on their belief that closures are badness and inner classes are goodness, and are now saying, no, closures are goodness after all.
Luke Hoban [MSFT] (Expert):
Q: One of the founding principles (it seems) of C# was to break free of some of the multi-methodology problems plaguing C++ (like the mix of OO and procedural). Do you think similar problems will arise by mixing OO and Functional?
A: I'm not sure to what extent avoiding "multi-methodology" problems in C++ was a goal of C#. I think the goals were more along the lines of raising the abstraction level (via the CLR, garbage collection, etc.) and targeting "component-oriented programming". There is an intentional mixing of functional and OO ideas happening in C# with C# 3.0, that will likely continue - and this enables a number of new APIs and ideas to be incorporated into C# - LINQ being one major example. For many of the important areas for the next generation (concurrency, dynamic, connected systems, etc.) a combination of object oriented and functional styles is likely to be valuable for APIs and coding patterns.
Keith Farmer [MSFT] (Expert):
Q: Any thoughts on the potential problems involving pollution with extension methods and if anything will be added to that respect post C# 3.0?
A: Currently, the concerns I've seen have been related to IntelliSense: obviously, string can present a problem because it implements IEnumerable, and I don't want to think about objects. We're working on ways to mitigate that without making extensions unattractive.
Luke Hoban [MSFT] (Expert):
Q: What kind of problems do expression trees solve? I've read and heard a lot of information regarding LINQ, extension methods, etc on the web, but little regarding expression trees.
A: The main problem expression trees solve is to enable API authors to capture the user’s code and process it. This is what LINQ to SQL does - capturing the user’s C# code into an expression tree and then converting this to SQL. There are many APIs which this enables which just weren't really possible before. For instance, there is an example of using expression trees for solving the MethodOf question that was raised earlier at https://weblogs.asp.net/cazzu/archive/2006/07/06/Linq-beyond-queries_3A00_-strong_2D00_typed-reflection_2100_.aspx.
Eric Lippert-MSFT (Expert):
Q: One of the founding principles (it seems) of C# was to break free of some of the multi-methodology problems plaguing C++ (like the mix of OO and procedural). Do you think similar problems will arise by mixing OO and Functional?
A: Yeah, to follow up on Luke's answer, I was not aware that addressing this problem was one of our goals! Ultimately our goal is for C# to be a practical, pragmatic language useful for a variety of general-purpose programming tasks, and that means making a language flexible enough to enable many different programming styles, while at the same time encouraging the writing of clear, understandable code. I personally do not see an impedance mismatch between OO programming -- promoting code reuse, abstraction via clean interfaces, and information hiding -- and functional programming -- promoting functions as objects and few side effects. I think they work together reasonably well in languages like JScript, and will continue to do so in C# 3.0.
Mads Torgersen[MSFT] (Expert):
Q: RE: compiler add-ins. I always thought being able to subscribe to an error event to be helpful. Having access to the source stream for modification while compiling would be neat.
A: The C# compiler is currently a very closed box. It would be neat indeed if we could somehow open it up more, and we may work towards that in the future, but don't expect anything anytime soon on that one.
Charlie Calvert-MSFT (Moderator):
Q: Will there *ever* be a conversion tool for old WinForms resources to XAML or is that near impossible?
A: I haven't heard about anyone working on something like this, but then again I've never really dug into it. You might want to check on the WPF forum and see if any one there knows more about this one: https://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=119&SiteID=1.
Eric Lippert-MSFT (Expert):
Q: To further "Theory’s question... have you looked at other ways of extending the language instead of continually adding new syntax? Perhaps opening the compiler to custom "add-ins" that would manage their own syntax snippets?
A: One idea that I know Anders has played around a bit with, and that I worked with a bit as well when I was on the VSTO team, goes like this: rather than extending the C# language itself, we could make it easier to develop new special-purpose languages which can be efficiently translated into C# and then executed. This is particularly useful when you think about more declarative markup languages (like XAML) that can be easily translated into classes and methods.
Luke Hoban [MSFT] (Expert):
Q: C++ is said to create the best IL code among those languages coming in Visual Studio. Will C# compiler come closer to that?
A: Depends what you mean by the best IL :) . The C# compiler does *very* few optimizations before emitting IL - so the IL is closer to what the user intended, but not as optimized up-front. The JIT is then left with the task of optimizing this, and generally does a good job. In fact, by leaving the optimizations until JIT time - there is knowledge about the execution environment which can be used to tune the optimizations - which can result in some benefits. However, there are also some more global optimizations which are harder to perform. So overall, it's hard to say which IL is better - it very much depends on the specifics of the JITs handling of certain constructs. But there is ongoing work on improving the JIT and in moving more of the C++ compiler's backend optimizations into the JIT.
Mads Torgersen[MSFT] (Expert):
Q: Why does there seem to be a disjoin between the quality of the C# compiler versus the VB.NET compiler; we have found the number of compiler errors to be drastically less with the C# compiler; what does your QA process look like....
A: Thank you for your positive words on the quality of the C# compiler. I don't really know of a difference in quality between that and the VB compiler; we have the same QA process in place, and work against the same divisional bars for bug fixes. Mind you that the VB compiler solves a harder task than the C# compiler, because it runs in the background of the IDE, continuously compiling your source code. The error tolerance demands are much, much higher and that may be why you experience more problems. Personally I am envious of the tight IDE integration that the VB team has managed to achieve.
Keith Farmer [MSFT] (Expert):
Q: @Keith: yes, we can always switch to an explicit call; but, let's say I have thousands of KLOC that use an extension method and we suddenly need to use some 3rd party assembly that declare an identical extension method. Switching to a static call seems...
A: .. To beg for better precision in extending types? Now's definitely the time to post suggestions on how you believe this can be improved! :) As has been noted with other great-feature suggestions, sometimes the problem is finding the syntax that we're willing to live with for the rest of C#'s life.
Eric Lippert-MSFT (Expert):
Q: I’m figuring that VS has some object model to describe C# source code. Any possibility that VS could expose that object model so that we could write code that would operate on our source code pre-compile time. Like through a console?
A: Today the source code model we have is very tightly bound to the compiler itself; it is nowhere near any kind of object model that we could expose for public consumption. However, in the LONG run, and we're talking multiple release cycles here, yes, I would love to have something like that exposed as a public API. The demands of modern compilers have moved well beyond just turning source code into object code. What we really need is a general-purpose library of semantic analysis tools, so that people can write their own refactoring engines and syntax colourizers and a million things we haven't thought of yet. I would love to do this work and I hope to do so over the next, say, ten years, but I want to emphasize that we are a long way from being in that position now.
Charlie Calvert-MSFT (Moderator):
There are about 15 minutes left in the chat. If there is a question you've been on the fence about, not quite sure if you want to ask, then this is a good time to go ahead and post. We are happy to try to answer any questions you might have.
Luke Hoban [MSFT] (Expert):
Q: @Luke: It might have been a comment from Eric G. relating to non-member functions and why that concept didn't make it into C# 1.0/2.0 was that it wasn't really object-oriented and those non-object oriented features of C++ were a hindrance to quality C++ code.
A: Interesting. It sounds like that was in response to a pretty specific question - and I can see how the distinction helps to clarify that particular issue.
Eric Lippert-MSFT (Expert):
Q: Anyone care to comment on implementation difficulties encountered during the development of C# 3?
A: I talk on my blog a lot about implementation difficulties we've had in C# 3.0. A big one is discovering places where C# 2.0 or 1.0 did not EXACTLY implement the spec, and a C# 3.0 feature depends upon the compiler exactly implementing the earlier standard. In those cases we have a tough choice -- make a breaking change, redesign the feature, implement it in a subtly broken way, etc. These are very tough calls and we get a lot of constituents involved before we make them. Another big area of difficulty was getting lambda analysis working correctly and efficiently. I have a long series of recent articles in my blog about how a subtle difference between lambda and anonymous method binding led to me having to rewrite HUGE amounts of the compiler to get it working correctly.
Mads Torgersen[MSFT] (Expert):
Q: We're doing a lot of work with Excel/Office. Lack of optional parameters & late binding (for versioning) is a pain when dealing with the Office PIA's. Are there any plans to make this easier, or will any improvements have to come from the Office team?
A: We are aware that working with the office PIA from C# causes excruciating pain. This is almost - but not quite - big enough to warrant a language change all on its own. We would like to add late binding and named parameters only if we feel it is valuable in general. For late binding, that may be the case now that the dynamic language runtime (DLR) has been announced and we may see major content contributed in languages such as Python and Ruby that are not easy to call into from C# today. As for named parameters, we're more on the fence.
Keith Farmer [MSFT] (Expert):
Q: Technically the IDE could process errors and provide an add-in the ability to hook that and modify the source "stream" (assuming the IDE had a separate copy); it would require the compiler to re-process the whole file though.
A: I think it'd be difficult for the IDE to provide the level of support people would expect, when it encounters that sort of situation. Generalizing against custom behavior and making it work well with the rest of the existing (or custom) IDE would be neat, but I suspect intractable. Of course, if you have ideas, let us know.
Luke Hoban [MSFT] (Expert):
Q: Any chances that we'll see something as inline IL (resembling C++'s inline assembly) some day in the future? C# covers most of the CLR's feature set, but there is stuff - particularly not CLI stuff - that is not covered.
A: There aren't any current plans for this that I am aware of. There are some tools available to merge custom IL into a managed binary that has been compiled with the C# compiler, and this approach seems to have worked for those who find they need it - though it requires more work.
Keith Farmer [MSFT] (Expert):
Q: @Keith: The problem, I see, is the lack of scoping. Extension methods attach outside of namespaces (for obvious reasons). I think there needs to be a way to scope them. That way two libraries with String.Reverse won't case grief.
A: I'd agree. I was making this very argument before I joined MS -- it's still a matter, I think, of finding a good syntax, though I'm hoping for as much.
Charlie Calvert-MSFT (Moderator):
About five minutes left. Please get in your last minute questions. We can probably handle a few more, so go ahead and let us know what you are thinking. Maybe a question about beta 1? Some other topic?
Eric Lippert-MSFT (Expert):
Daniel/Paul: yeah, the code model isn't really what we need. It is a nice way to cons up some C# code from an abstract syntax tree, but what Paul is asking for is to go the other way -- to have a bunch of code, possibly not syntactically correct, in an editor, and be able to efficiently extract syntactic and semantic analysis from it. A hard problem, one that we have solved in a very one-off and ad-hoc manner historically. Solving the problem more cleanly and generally will enable a lot of wins, but it will take time.
Keith Farmer [MSFT] (Expert):
Q: @Keith: ...without diluting the flexibility of extension methods... Which is where the challenge lies.
A: Exactly
Mads Torgersen[MSFT] (Expert):
Q: General thoughts on Mono project?
A: There's a simple answer to that: We love it! As the only major implementation of the ECMA/ISO standards besides our own, Mono means a lot to us in terms of validating the technology. We also think that it is great to have our inventions used in settings that are not profitable for us to invest in. I wish there were more people out there doing their own implementations. While we do talk to the Mono people occasionally, they make a point of being independent from us, and I can see why, so we generally don't engage too much. But I do think they rock!
Charlie Calvert-MSFT (Moderator):
Q: Currently the compiler places any object > 85 in the LOH. The exception to that is a real array which goes in at ~10K. If one is creating/destroying these 10k real arrays the LOH gets fragmented. Is there any way to not have the item go into the LOH?
A: I'm sorry OmegaMan, but I don't think anyone here has the answer to this one. Maybe there is some way we can get it resolved off line. (ccalvert@microsoft.com)
Keith Farmer [MSFT] (Expert):
A: Daniel: Charlie tries to keep them at bay...
Eric Lippert-MSFT (Expert):
Q: Will there be any changes in the language from beta 1 to RTM?
A: A few. Mostly bug fixes and performance work. (Compilation perf of deeply nested lambdas is ABYSSMAL in beta 1, I apologize, I did not have time to get the perf refactoring in by the time we shipped the beta.) The biggest design change that comes to mind is that anonymous types will be immutable post beta 1. See Sreekar Choudhary's blog and my blog for the details of that design change.
Mads Torgersen[MSFT] (Expert):
Q: C#. Is. Awesome. Your thoughts?
A: Thanks! I. Like. To. Hear. That! Anything you feel you still miss from it though?
Eric Lippert-MSFT (Expert):
Q: @Eric: Yea, I keep thinking how powerful a feature like that would be. Do you think that is a problem that is getting any attention? Do you see any support behind it in the near future, or is something like that years away?
A: This is an area of active research at Microsoft. I feel like there is huge potential for innovation here. But it will take multiple releases to get to where I want it to be.
Charlie Calvert-MSFT (Moderator):
Q: I am getting an error message when I startup my computer that says "NTLDR is missing" and would like to know how to resolve this problem
A: This is really outside the scope of our expertise, but here is a link which points to a place where you might be able to get some help: https://support.microsoft.com/default.aspx/kb/320397/
Luke Hoban [MSFT] (Expert):
Q: @Luke: Indeed, I don't think I'd directly advocate post-compile assembly processing/IL Merging (slow, although you're free to do whatever you want you lose lots of detail). But, pushing the compilers into the familiar events model does seem intriguing
A: Compiler hooks are something that we've thought about - but this would be a significant change to the compiler, and we haven't yet found a case that needs this that really justifies it. The case of accomplishing inline IL for instance, is not a major concern that we've heard, and does have a workaround (though definitely hacky). Also, some of that hackiness does seep through into any solution where you hook into the compiler, and many of the guarantees we are currently able to make are lost.
Keith Farmer [MSFT] (Expert):
Q: @Keith: do you think not solving the ext. method pollution problem before release will cause problems even more difficult to resolve?
A: The problem occurs when we discover that our "solution" actually prevents a better, more flexible solution later on. Consider the problems related to System.Exception being both catchable and instantiable. We can't go back on that one very well now, since it'll break code.
Charlie Calvert-MSFT (Moderator):
We are out of time!
Mads Torgersen[MSFT] (Expert):
Q: Thanks for the chat folks. Much appreciated!
A: You're welcome - and thank you, too! Great feedback as always - keep coming, guys!
Charlie Calvert-MSFT (Moderator):
Thank you for attending the chat. We will try to wrap up the last questions in the queue, and then call it a day. Thanks again for taking the time to come here and ask questions and generate a bit of discussion.
Charlie Calvert-MSFT (Moderator):
Come back again in two weeks and we will have another chat with the LINQ to SQL team!
Luke Hoban [MSFT] (Expert):
Thanks everyone for the great questions! If you've got anything else you want to chat about offline - send me email at lukeh@microsoft.com - or through my blog at https://blogs.msdn.com/lukeh.
Charlie Calvert-MSFT (Moderator):
Q: @Luke: it spawned from questions relating to ext. methods and their similarity to non-member functions, it deviated into a conversation about some of the principles of C#...
A: Peter, sounds like you might have to take this up with Luke offline. Write me if you have questions.
Mads Torgersen[MSFT] (Expert):
Q: @mads: Better interaction with COM. But I can get over not having that if it keeps the language in its current state of Awesome.
A: Yup, COM Interop is a biggie. But big enough to warrant a whole new call syntax? I promise you that we will be looking at it again for 4.0 (or whatever the number ends up being) but I can't promise you we'll pursue it. Personally I'm in favor if we can get the versioning issues sorted out.
Eric Lippert-MSFT (Expert):
Q: Anything C/C++/Java/JS (c-family) offers now that you would REALLY like to implement in C# that isn’t?
A: I personally would love to have more co- and contra-variance in the generic type system without losing type safety. I think Java has some interesting ideas about unconstructed generic types. But all the features in JScript that I wanted to get into C# we have put in C# 3.0 and then some.
Eric Lippert-MSFT (Expert):
Q: @Eric: Does that research have a webpage at all where one could learn more about the idea and its status of maturity/implementation?
A: Not to _my_ knowledge, but that doesn't mean there isn't one. :-) MSR is huge!
Charlie Calvert-MSFT (Moderator):
Q: @Charlie: Is it possible to increase the amount of text that can be posted from the text box. The 256 char limit can be kind of hard to work with sometimes. Just a suggestion for future chat sessions.
A: Sorry about that limitation. I'll ask around and see if there is a solution. We might try experimenting with using Live Meeting too.
Mads Torgersen[MSFT] (Expert):
Q: Is the C# compiler going to use Phoenix compiler technologies?
A: We don't know yet. Ideally we would love to, but porting over is a big investment, so we'll have to prioritize and trade-off against other cool stuff we'd like to do. Phoenix is awesome, though, and if we were starting from scratch it would be a no-brainer.
Charlie Calvert-MSFT (Moderator):
Q: Next version Orcas beta (2?) Download the whole DVD instead of in parts?
A: I think there are some technical reasons why we can't do that. I think it would be nice if we tried splitting them in half, perhaps, rather than so many sections. A little script to help with the download might also be useful.
Charlie Calvert-MSFT (Moderator):
Q: @Charlie: Great! Thanks for checking it out.
A: No problem.
Eric Lippert-MSFT (Expert):
I'm off to lunch. Thanks for all the good questions!
Eric Lippert-MSFT (Expert):
Feel free to post comments on my blog if you have more questions.