Breaking Change in Linq Queries Using Explicitly-Typed Range Variables

re: Breaking Change in Linq Queries Using Explicitly-Typed Range Variables

Zooba — Sat, 16 Feb 2008 07:19:48 GMT

Thanks for this information. Breaking changes aren't so bad when the issue and reasoning are clearly explained.

Round-to-even is just weird. Personally (as a very low-level and also a high-level developer) I see no need for any intrinsic rounding besides round-down (truncation for positive numbers). Every other rounding method can be easily emulated from this base.

LINQ表达式中关于显式范围变量的Bug

Adrian H. — Sat, 16 Feb 2008 18:07:28 GMT

MSDN博客中的一篇文章提到了.NET3.5SP1会带来的处个修正，见以下代码： varfloats=newArrayList{2.5f,3.5f,4.5f}; ...

re: Breaking Change in Linq Queries Using Explicitly-Typed Range Variables

Randolpho — Tue, 19 Feb 2008 00:09:56 GMT

Thankfully this won't affect me, but.... I was wondering where Ican find info on the .NET 3.5 Service Pack 1. Google hasn't been my friend...

When is it due to ship?

re: Breaking Change in Linq Queries Using Explicitly-Typed Range Variables

alunharford — Tue, 19 Feb 2008 18:42:57 GMT

Ouch! The original behavior was bad, but "it might behave the bad way, or another way, depending on what version of the CLR it's running on" is much worse.

Developers could finding themselves fighting the "how does it behave when modulus operations are buggy" battle that has done so much damage to the Java platform.

This change should have been left until version 4.

re: Breaking Change in Linq Queries Using Explicitly-Typed Range Variables

kfarmer@microsoft.com — Tue, 26 Feb 2008 04:01:33 GMT

alunharford: Given that the age of any (legal) code is still fairly young, I wouldn't expect this to be painful to correct to conform to the suggestion of not explicitly stating the range type. Indeed, for the large majority of LINQ users, I doubt there's been a need to state the range type at all.

Given the performance benefit of the fix and what I figure will be relatively few *actual* breakages, I think it's appropriate to do this change now. Heck, even those which would break have plenty of time to code around the breaking area. They could conceivably write their own cast operator if they wanted.

Waiting until version 4 would have given an established base of code that would be much larger and more complex. You would have to create a Cast2<T> method, which would just be wrong.

Community Convergence XLI

Charlie Calvert's Community Blog — Wed, 12 Mar 2008 00:41:26 GMT

Welcome to the forty-first Community Convergence. The big news this week is that we have moved Future

re: Breaking Change in Linq Queries Using Explicitly-Typed Range Variables

jonskeet — Sat, 15 Mar 2008 03:58:04 GMT

Slightly strange question, I know - but why is the call to Select(i => i) included in the first place? Shouldn't it be removed as a degenerate query expression, given that there's a call to Cast?

What's New in the June 2008 CTP of Parallel Extensions

Parallel Programming with .NET — Mon, 02 Jun 2008 18:57:44 GMT

We've just released a new community technology preview (CTP) of Parallel Extensions to the .NET Framework!

.NET Framework 3.5 SP1: LINQ perf improvements (LINQ to Objects and LINQ to SQL)

Dinesh's Cyberstation — Mon, 11 Aug 2008 20:02:46 GMT

There are three perf improvements in the soon to be released SP1 . As always, I will let you run your

Important LINQ Changes in .NET 3.5 SP1

Marco Russo — Tue, 12 Aug 2008 10:50:47 GMT

Dinesh Kulkarni wrote an important post about changes in LINQ introduced by .NET 3.5 SP1 that has been

Important LINQ Changes in .NET 3.5 SP1

SQLBI - Marco Russo — Tue, 12 Aug 2008 10:50:51 GMT

Dinesh Kulkarni wrote an important post about changes in LINQ introduced by .NET 3.5 SP1 that has been

Breaking Changes in SP1 for Visual Studio 2008 and .NET 3.5

Andreas Lehmann — Wed, 13 Aug 2008 11:09:41 GMT

I found some interesting blog posts about breaking changes in the SP1 for Visual Studio 2008 and the