[Mono-dev] Standard name for mcs
jonpryor at vt.edu
Wed Jun 30 11:28:36 EDT 2010
On Sun, 2010-06-27 at 21:29 +0100, Russell Wallace wrote:
> On Sun, Jun 27, 2010 at 9:22 PM, Mark de Bruijn | Dykam
> <kramieb at gmail.com> wrote:
> > The problem is that not all version of C# are completely backwards
> > compatible themselves.
> I was under the impression Microsoft were being very careful about
> maintaining backward compatibility in both the language and the
They do, but they only try so hard.
For example, the semantics of token evaluation changed from C#1 to C#2
due to generics, e.g. the parsing of
In C#1, that would be a call to F(bool, bool) with `G<A` as the first
argument, and `B>7` as the second argument.
In C#2, the semantics are changed so F(T) is looked for, and the generic
method G<A,B>() is invoked with the value 7.
Most of the breaking changes between C#1 and C#2 are of this manner.
There are other breaking changes between C#3 and C#3 SP1, e.g.
Most of these could be argued as "corner cases" where the implementation
didn't meet the spec (e.g. fixing double invocation of 'finally' blocks,
ensuring that 'params' within indexers matches the interface, etc.).
Then there's moving from C#3 to C#4:
Most of these are changes due to the new C#4 language features.
> If that fails, it's basically going to be a choice between
> going back to Java (which I'd rather not do) or back to C++ (which I'd
> really rather not do).
Java is a stagnant language, which has taken back-compat to such an
excess that improving the language is near impossible (which is likely
why other JVM languages like Scala are increasingly popular).
C++ isn't necessarily any better, either: there are lots of compiler
bugs, non-standardized compiler extensions, and the language itself will
be changing things (e.g. `auto` is being repurposed in C++-1x, thus
changing the semantics of a previously defined (and deprecated)
Also, if we take the above C#3 to C#3 SP1 list as a guide, any compiler
fix that is done to better match the spec would be a breaking change,
and when we have compilers "chasing" and/or "leading" the spec (as is
true for most of the C++-1x features), things WILL change to be more
conformant with the spec.
In short, for ANY language which is actually changing (even minimally),
"breakage" is going to be a possible factor. The only languages where
this isn't true is for dead languages which aren't changing anymore (and
arguably aren't being used much anymore because they haven't changed).
More information about the Mono-devel-list