Charlie Calvert's Community Blog

Visual Studio 2008 Beta 2 was released to the web for download today. The releases are available both

You've been kicked (a good thing) - Trackback from DotNetKicks.com

You guys rock! This needed to be done for a long time (and I'd put in requests on Connect a long time ago, accordingly).

A week to review a spec this big isn't very long though for people who are most likely to be doing it in their spare time. I appreciate the existence of the spec, but the "public review" period seems like a fairly useless token gesture. A few months of regularly updated public drafts would have made more sense. This is better than nothing, but - as far as public review goes - not nearly enough.

Still, very pleased you finally combined the specs :)

Section 8.12 has the following detail:

where x is an expression of a reference-type, is precisely equivalent to

System.Threading.Monitor.Enter(x);

try {

...

}

finally {

System.Threading.Monitor.Exit(x);

}

I don't think it's accurate to say it's "precisely equivalent".  I think it's more equivalent to:

Object temp = x;

System.Threading.Monitor.Enter(temp);

try {

...

}

finally {

System.Threading.Monitor.Exit(temp);

}

lock(x) {...} has a distinct advantage over

System.Threading.Monitor.Enter(x);

try {

...

}

finally {

System.Threading.Monitor.Exit(x);

}

... in that the following:

lock(x)

{

x = new Object();

}

....will not generate a SynchronizationLockException.

A última versão da especificação do C# que inclui a versão 3.0 foi liberada para download e revisão pela...

I complement the last my comment.

In the case of delegate, there is no problem.

Func<bool, Func<bool>> identity = cond => () => cond;

var _true = identity(true);

Console.WriteLine(_true());

var _false = identity(false);

Console.WriteLine(_false());

Console.WriteLine(_true());

// True False True ... OK

This result is guaranteed by this spec, I think.

But in the case of expression tree, the result is different from the delegate case (in Orcas beta 2).

Expression<Func<bool, Func<bool>>> expr = cond => () => cond;

var identity = expr.Compile();

var _true = identity(true);

Console.WriteLine(_true());

var _false = identity(false);

Console.WriteLine(_false());

Console.WriteLine(_true());

// True False False !!!!!!

I have not found any definition or statement that guarantees the semantics of "compile-time generation of Expression Trees" and "runtime compilation of Expression Trees".

I think this spec is where the semantics should be declared.

The following bits should be better specified.

7.4.2.1

if ei is an anonymous function or a method group, an explicit parameter type inference (§7.4.2.7) is made from ei with type Ti

otherwise an output type inference (§7.4.2.6) is made from ei with type Ti

It's unclear what happens when there is no explicit parameter or an anonymous method or lambda expression are parameterless.

7.4.2.2

All unfixed type variables Xi which do not depend on (§7.4.2.5) any Xj are fixed (§7.4.2.10).

I think "do not depend on" should be "do not depend directly on" in this particular case.

7.5.10.4 Anonymous types

The section should list all expressions which are non-assignable to anonymous type properties and not just null and unsafe types.

Ok, so after being published on the VS Start Page on Aug-9th, how can we submit feedback?!

To gild refined gold, to paint the lily,

To throw a perfume on the violet,

To smooth the ice, or add another hue

Unto the rainbow, or with taper-light

To seek the beauteous eye of heaven to garnish,

Is wasteful and ridiculous excess

King John. Act iv. Sc. 2.

To put it more directly if less elegantly, how about fixing the bugs instead of mucking about with syntactic sugar for things we can already do with design patterns and some common sense?

I could, for example, send you some code that works perfectly on a single CPU system but intermittently hangs on a multi-CPU system when it hits Control.Invoke() - the clue here is that this problem only occurs when the invoked method is on another object (visitor pattern). When you merge the method into the class of the object on which it operates the problem goes away.

Perhaps it might be wise to solve the problems we have before creating new ones?

For example, how about a straightforward way to install a global exception handler on a windows service? As things stand, when the network glitches and a socket closes unexpectedly you get an InvalidOperationException in mscorlib and remoting dies taking out the whole service.

(If there is already a way in 2.0 to handle this scenario please tell me and I will sing your praises from the hilltops.)

I've been writing about type inference *very* recently, based on the previous C# 3 spec (the "add-on" version). In other words, I think I know reasonably well how it works in any particular situation.

This morning I looked at the spec to see how well my understanding matched up to the current spec... and I couldn't understand a word of it! Okay, that's going a bit far, but the type inference section is really, really dense. That's not completely inappropriate for a spec, but I don't think it would be reasonable to expect anyone to read that section and learn about type inference from it, without a significant starting point.

Of course, it's easy to criticise - I fully appreciate that actually *fixing* the readability issue is insanely difficult.

(And to echo some other comments - thanks for putting this out!)

Jon

Oops, I might a slight mishap in previous note, both 6 is logical, res2 probably results in 7 in given sample. Experience told me at least the userimplemented postincrement is treated the same as preincrement.

After reading this i am very thankful to Microsoft team to provide us such a best collection.