3 ms·

This does not belong in C#; this belongs in the CLR. If they don't do this as an upgrade to the CLR, then they are effectively admitting that "common language"

This does not belong in C#; this belongs in the CLR. If they don't do this as an upgrade to the CLR, then they are effectively admitting that "common language" is dead and a joke, even more so than now. (Where libraries, even MS-shipped, make API decisions based on C# compiler implementation details.) On the plus side, they're finally talking about something that should have been addressed back in 1999. The downside is that C# seems to be getting a lot more complicated due to having to graft this stuff on in an ugly way. I agree the language needs tons of work. I just wish they had better fundamentals so it was neater. F# already has most of what C# can aspire to be, but it feels far less complicated.

dogma1138 11y ago
I'm not sure what you mean exactly but there are already differences between various .net languages there are things you can do with C# that you can't really do with VB.NET easily even simple things like bit-wise operators or the fact that you have literal control of overloads in VB which you lack in C# and the list goes on and on. Since the languages them selves work quite differently the interpreter and the CLR can't really treat them the same way heck if you make something simple lika a hello world in VB and C# the MSIL won't be identical. And with the current nullable support then currently supported Nulleable Type Values for VB.NET and Nullable Types for C# don't really work exactly the same way because they still need to conform to the specification of their language first and then to the CLR.
- MichaelGG 11y ago
  The idea is that major type features should be exposed via common metadata and represented in the IL. This allows other languages to unambiguously use such types. Non-nullable references are definitely a big enough feature. Conceptually, it's bigger than Nullable<T> which is just a wrapper you can toss around any struct and could be done purely as a library (though I understand there's some delicacy as far as unboxing null and converting that to a Nullable<T>). I'm not sure which interpreter you're referring to, but languages don't need to emit similar IL for executable code (why would it matter?). What counts is that the type defs end up exported in the same manner. If making a class in VB emitted substantially different IL than C#, that'd be an issue.
CmonDev 11y ago
F# might be succinct but it is most definitely complicated.
- thomasz 11y ago
  Case in point: You can define a type as an enum, a discriminated union, a record type, an interface, an abstract class, a class or a struct. You can have a primary constructor for a class or struct, or like a method with the new() keyword. You have namespaces and modules.
  - MichaelGG 11y ago
    F# also has first-class tuple types. But the better way to look at it is that you can have records and can put them in sum and products. Then for compat, there's the types for .NET's OO system. But sure, that's an increase in complexity in F#. Yet in C# you have hard-coded keywords for things like System.Threading.Monitor (the lock keyword). This doesn't exist in F#-the-language, but is implemented via a simple function so it doesn't count. (Just like you wouldn't consider System.Math.Max part of C#-the-language). In C#, you have hard-coded operators, whereas in F# they're essentially just functions (compile-time type parameters work similar to _Generic in C11). In C# you have hard-coded LINQ and async syntax, whereas in F# you don't (just one general construct for computation expressions). People cite stuff like F# pipelining, but that's not a language feature, it's just a function. C# and F# both have quotations, but F#'s are more complete, not a one-off to implement LINQ-to-SQL. That reduces complexity, or is at least a tie. (In the way that arithmetic over integers is less complex than arithmetic over int32.) Type extensions are another case of this. C# has them, but only partially implemented (extension methods), whereas F# implements the feature in a less complex way that provides more coverage. OTOH, F# does stuff like transforming Int32.TryParse to match as a tuple (nice, but a complication). And it also has really ugly things like this one: Explicit parameter names take higher binding than = operator. Example: Foo(Bar = Baz) // Calls Foo with argument Bar with value Baz Foo((Bar = Baz)) // Calls Foo(bool) with result of (=) Bar Baz My gut feeling is that once you subtract F#'s stdlib and add in C#'s plethora of edge cases, you're not actually significantly less complex in a meaningful way using C#, and F#'s improved uniformity wins out.
ygra 11y ago
Correct me if I'm wrong here, but those things have to be done at the CLR level anyway. Otherwise the compiler couldn't warn about wrong usage of method declarations in external libraries (as one example in the proposal shows). For that to work the types or parameters would need to be atributed in some way in the IL. And then it's not only a C# compiler feature anymore.
- wvenable 11y ago
  The CLR already supports arbitrary attributes on methods and parameters. So one could implement this entirely in the language and still target old versions of the CLR.
  - MichaelGG 11y ago
    They can smuggle it in via attributes. But if they don't make this part of the CLR spec, then not really cross-platform and more like C#'s extension methods. Ideally these features would be designed at a higher level, in the CLR, aimed to target as many languages as possible. I.e., they shouldn't be proposed as C# extensions.

dogma1138 11y ago

I'm not sure what you mean exactly but there are already differences between various .net languages there are things you can do with C# that you can't really do with VB.NET easily even simple things like bit-wise operators or the fact that you have literal control of overloads in VB which you lack in C# and the list goes on and on. Since the languages them selves work quite differently the interpreter and the CLR can't really treat them the same way heck if you make something simple lika a hello world in VB and C# the MSIL won't be identical. And with the current nullable support then currently supported Nulleable Type Values for VB.NET and Nullable Types for C# don't really work exactly the same way because they still need to conform to the specification of their language first and then to the CLR.

MichaelGG 11y ago
The idea is that major type features should be exposed via common metadata and represented in the IL. This allows other languages to unambiguously use such types. Non-nullable references are definitely a big enough feature. Conceptually, it's bigger than Nullable<T> which is just a wrapper you can toss around any struct and could be done purely as a library (though I understand there's some delicacy as far as unboxing null and converting that to a Nullable<T>). I'm not sure which interpreter you're referring to, but languages don't need to emit similar IL for executable code (why would it matter?). What counts is that the type defs end up exported in the same manner. If making a class in VB emitted substantially different IL than C#, that'd be an issue.

CmonDev 11y ago

F# might be succinct but it is most definitely complicated.

thomasz 11y ago
Case in point: You can define a type as an enum, a discriminated union, a record type, an interface, an abstract class, a class or a struct. You can have a primary constructor for a class or struct, or like a method with the new() keyword. You have namespaces and modules.
- MichaelGG 11y ago
  F# also has first-class tuple types. But the better way to look at it is that you can have records and can put them in sum and products. Then for compat, there's the types for .NET's OO system. But sure, that's an increase in complexity in F#. Yet in C# you have hard-coded keywords for things like System.Threading.Monitor (the lock keyword). This doesn't exist in F#-the-language, but is implemented via a simple function so it doesn't count. (Just like you wouldn't consider System.Math.Max part of C#-the-language). In C#, you have hard-coded operators, whereas in F# they're essentially just functions (compile-time type parameters work similar to _Generic in C11). In C# you have hard-coded LINQ and async syntax, whereas in F# you don't (just one general construct for computation expressions). People cite stuff like F# pipelining, but that's not a language feature, it's just a function. C# and F# both have quotations, but F#'s are more complete, not a one-off to implement LINQ-to-SQL. That reduces complexity, or is at least a tie. (In the way that arithmetic over integers is less complex than arithmetic over int32.) Type extensions are another case of this. C# has them, but only partially implemented (extension methods), whereas F# implements the feature in a less complex way that provides more coverage. OTOH, F# does stuff like transforming Int32.TryParse to match as a tuple (nice, but a complication). And it also has really ugly things like this one: Explicit parameter names take higher binding than = operator. Example: Foo(Bar = Baz) // Calls Foo with argument Bar with value Baz Foo((Bar = Baz)) // Calls Foo(bool) with result of (=) Bar Baz My gut feeling is that once you subtract F#'s stdlib and add in C#'s plethora of edge cases, you're not actually significantly less complex in a meaningful way using C#, and F#'s improved uniformity wins out.

ygra 11y ago

Correct me if I'm wrong here, but those things have to be done at the CLR level anyway. Otherwise the compiler couldn't warn about wrong usage of method declarations in external libraries (as one example in the proposal shows). For that to work the types or parameters would need to be atributed in some way in the IL. And then it's not only a C# compiler feature anymore.

wvenable 11y ago
The CLR already supports arbitrary attributes on methods and parameters. So one could implement this entirely in the language and still target old versions of the CLR.
- MichaelGG 11y ago
  They can smuggle it in via attributes. But if they don't make this part of the CLR spec, then not really cross-platform and more like C#'s extension methods. Ideally these features would be designed at a higher level, in the CLR, aimed to target as many languages as possible. I.e., they shouldn't be proposed as C# extensions.