This will be my last post before I head off for my annual vacation in Canada; see you again in September for more Fabulous Adventures in Coding!
Last time on FAIC I suggested a rule for translating nested “from” query expressions into a much simpler form than the C# specification requires. Why does the C# specification not use my simplified form?
In fact what I showed yesterday is pretty close to what the LINQ translation rules for
SelectMany queries looked like shortly before shipping C# 3.0. The problem with it becomes apparent when you consider the following: Continue reading
Seriously, what is it? It’s not a rhetorical question. I realized this morning that I am totally confused about this.
First off, let me say what I thought “duck typing” was. I thought it was a form of typing.
So what is “typing”? We’ve discussed this before on this blog. (And you might want to check out this post on late binding and this post on strong typing.) To sum up:
Today on the Coverity Development Testing Blog‘s continuing series Ask The Bug Guys, I take a question from an “Eric L”, who is confused about one of the subtle rules of method type inference despite having written the rule himself. My colleague Jon takes a question from a beginner C programmer about memory allocation.
As always, if you have questions about a bug you’ve found in a C, C++, C# or Java program that you think would make a good episode of ATBG, please send your question along with a small reproducer of the problem to
TheBugGuys@Coverity.com. We cannot promise to answer every question or solve every problem, but we’ll take a selection of the best questions that we can answer and address them on the dev testing blog every couple of weeks.
Suppose we have my usual hierarchy of types,
Giraffe, etc, with the obvious type relationships. An
IEqualityComparer<T> is contravariant in its type parameter; if we have a device which can compare two
Animals for equality then it can compare two
Giraffes for equality as well. So why does this code fail to compile?
IEqualityComparer<Animal> animalComparer = whatever;
IEnumerable<Giraffe> giraffes = whatever;
IEnumerable<Giraffe> distinct = giraffes.Distinct(animalComparer);
This illustrates a subtle and slightly unfortunate design choice in the method type inference algorithm, which of course was designed long before covariance and contravariance were added to the language.
This is part two of a two-part series on dynamic contagion. Part one is here.
Last time I discussed how the
dynamic type tends to spread through a program like a virus: if an expression of
dynamic type “touches” another expression then that other expression often also becomes of
dynamic type. Today I want to describe one of the least well understood aspects of method type inference, which also uses a contagion model when
dynamic gets involved. Continue reading
Here’s a question I got from a coworker recently:
It is obviously important that the C# compiler not go into infinite loops. How do we ensure that the method type inference algorithm terminates?
The answer is quite straightforward actually, but if you are not familiar with method type inference then this article is going to make no sense. You might want to watch this video if you need a refresher. Continue reading
Once again today’s posting is presented as a dialogue, as is my wont.
var sometimes required on an implicitly-typed local variable and sometimes illegal on an implicitly typed local variable?
That’s a good question but can you make it more precise? Start by listing the situations in which an implicitly-typed local variable either must or must not use
Sure. An implicitly-typed local variable must be declared with
var in the following statements: