8 ms·

C# 7 Proposal: Nullable reference types and nullability checking

84 points by Permit 11y ago

inglor 11y ago
There is no way they can introduce a breaking change _this big_ into the language. This change effectively breaks almost every big piece of C# code.
- mikko_m 11y ago
  As described in the proposal, it's supposed to be an opt-in feature.
  - inglor 11y ago
    It would be impossible to _actually_ have a feature like this as opt in since it would effectively create two different versions of C#. What the proposal does is emit warnings (and not errors) which is another shame. I'd much rather have it opt in at the class declaration level like: `strong class Foo` Where strong means references to it act like value type references with regards to nullability. Alternatively, they can just fork C# and remove all the weird parts they've accumulated over the years and stay with a sub-language that's more powerful and they can add useful features on top of.
    - jeswin 11y ago
      > would be impossible to _actually_ have a feature like this as opt in since it would effectively create two different versions of C# You still haven't said what's wrong with the proposal. There are multiple versions of C# already. Emitting warnings seems to be a good compromise, given there is already an option to treat warnings as errors. >`strong class Foo` This is a slippery slope. Next time they add another feature for correctness, they'll have to add 'stronger class'. This is akin to "use stricter" proposed by Sound Script (JS).
      - jaked89 11y ago
        In big codebases, warnings are useless. No one reads them. They usually contain thousands of items from different plugins, designers, etc. Sorting through them all is impractical. Errors are not just about protecting a developer from himself, but more importantly, protecting developers in a team from one another. If the compiler can't produce an error, the whole feature is pointless.
        DrJokepu 11y ago
        I worked on some fairly large C# projects where the teams had zero-warning policies. It's not that difficult to achieve with a bit of discipline. Warnings in third-party dependencies only show up if you build them from source, but these days it's a lot easier to get your third-party dependencies from NuGet instead. That being said, I don't think warnings would be a good way to go on this case, because the sheer number of warnings generated by these new rules in existing, large (and mostly bug-free) projects would make it very difficult to reestablish a zero-warnings state. Developers on the team will just get undisciplined due the the broken windows effect.
        AndrewDucker 11y ago
        Yup. We have a zero-warning policy, and there's a setting in every project you can enable to treat warnings as errors, which we use.
        Locke1689 11y ago
        Warn-as-error can be set for individual warnings as well as for every warning. However if your build is spitting thousands of warnings and no one cares, that sounds like an issue someone should be looking at...
      - Dylan16807 11y ago
        > You still haven't said what's wrong with the proposal. "The feature will not provide airtight guarantees, but should help find most nullability errors in code." That seems like a pretty big flaw, but it's still an improvement. And it's not exactly a slippery slope to add more kinds of strict. Here, have a syntax: use strict(a, b, c).
- olavk 11y ago
  I don't see what it will break? Sure you might get a lot of warnings if you upgrade (if I understand the proposal correct), but everything is going to work just as before.
DiabloD3 11y ago
I completely agree with this proposal, especially since this seems to be opt-in, otherwise a lot of "probably bug free" code would suddenly break. If this makes it into 7, a lot of code should at least be attempted to be converted to this to cut down on an entire class of bugs. Seriously, Microsoft is making me happy that they're taking the whole "languages should make the job of the programmer easier, not harder" thought process seriously.
- jimktrains2 11y ago
  I only used C# for a few months, a few years ago, but I immediately loved the language. I wasn't thrilled about the documentation (Why aren't return types listed in [1]?), VS (OK, vim key bindings made more bearable), or just dealing with the MS ecosystem in general, but I loved the language. It felt like everything Java was suppose to be, but is failing at. [1] https://msdn.microsoft.com/en-us/library/system.string%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/system.string%28v=v...
  - mattmanser 11y ago
    Because it's a statically typed language it's all in the IDE. Almost everyone who uses C# doesn't need to check the documentation for that kind of information, it comes up when you're typing, or it's an ctrl-space away if your caret is on a method, or you can right-click go to definition. You can pretty much right click on anything and go to definition, which will show you all the method signatures and return types of everything. My only beef with the documentation is that they show examples of the code in use, but annoyingly never the output. So, for example, it's never clear even from the examples in the documentation whether a directory path or a URL includes a trailing slash or not. And because there's no REPL, you have to either build/compile/run or use an external program (I used to use some LINQ tester program that was basically a REPL, but it's contextually almost as expensive as simply trying it in an existing program).
    - Locke1689 11y ago
      > And because there's no REPL Working on it -- you can expect a public pre-release soon. The code is in master right now: https://github.com/dotnet/roslyn/tree/master/src/InteractiveWindow https://github.com/dotnet/roslyn/tree/master/src/Interactive.... I'll have to check with the dev to see how installing it is supposed to work, but he demo'd it on Friday and it looked very slick.
Maarten88 11y ago
I have not even started using C#6, which introduces the Null-Conditional operator. I expect this to already cleanup a lot of that verbose null-checking code, and avoid null reference exceptions simply because checking for null gets so much easier. To me, as a C# dev, this proposed change seems rather quick (let C#6 get some use first) and it also seems not consistent with nullable value types: with a reference type you'll get a compiler warning where the same error on a value type will give an error.
- jasode 11y ago
  >To me, as a C# dev, this proposed change seems rather quick (let C#6 get some use first) ... Not really. The non-nullable references feature request has been on the radar for many years. (E.g. this July 2009 stackoverflow post[1]). There are also some very old MS channel9 videos where Anders Hejlsberg acknowledged that the community wants this safety feature and discusses the difficulties of implementing it. I don't have a link to the video but this 2008 stackoverflow post mentions a Computerworld interview on the topic.[2] Non-nullable references is not a shoot-from-the-hip feature addition, and the C# team has been thinking about it for a very long time [1]http://stackoverflow.com/questions/411906/c-sharp-net-design-flaws http://stackoverflow.com/questions/411906/c-sharp-net-design... [2]http://stackoverflow.com/a/178090 http://stackoverflow.com/a/178090
- CmonDev 11y ago
  Two year release cycles are quick for you?
  - Maarten88 11y ago
    No, but Visual Studio 2015 came out July 20, only 7 weeks ago. I've been using it 3 weeks now. I find it difficult to judge a proposed feature when there was so little time to get used to the current situation. Maybe it's a great idea, I don't know. It looks like the next step beyond the Null-Conditional operator. I'll be migrating a lot of code to use that in the coming weeks. After that I'll have a much better idea how much I like this idea.
MichaelGG 11y ago
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.
alkonaut 11y ago
While I think these C#7 proposals are all cool features (Non-null, tuples, pattern matching), it feels almost like it's too late to make improvements of this kind to C#. We have had F# for a very long time, do we really need non-null and pattern matching and so on in C#? The features sure make sense for C#, but do they make sense now? As more and more features come into C#, all of the BCL would have to be updated to use them if they are to deliver their full value. When generics entered in .NET 2.0, the generic and non-generic collections API were both included in the BCL, and they still are. I can't see how it would be as easy to make the BCL take full advantage of proper tuples, non-nullables etc., in a way that doesn't feel like a complete afterthought. I'm all for adding features, and I'd be happy to get breaking changes and update thousands of lines of code to get them. But I fear that isn't going to happen, instead things will come in as optional features, the BCL won't be updated to return tuples where it should (I.e. whereever it would have if the feature had been around forever), and so on.
- AndrewDucker 11y ago
  It might be too late to update the BCL with them. But that doesn't make it too late to bring the updates to people who work with C# all the time. I maintain a bunch of C# codebases, and I'd love to have more updates to the language.
- MichaelGG 11y ago
  Unfortunately, since people are dumb[1], we're stuck with C#. So they might as well improve it as much as possible. This feature could be layered on top of the BCL as extra metadata. Sorta like TypeScript allows you to add type annotations to third-party libraries, C# could take that approach with null. (Yes, this is sorta ugly.) With tuples, C# can take F#'s approach and special-case common patterns (like TryParse that use out parameters). There's probably only a few patterns where this matters and you'd get most of the benefit. (And I suppose you could always provide annotations to note how to match certain non-tuple-returning functions.) 1: There's really no reason to use C# when we have F#, unless the app is some crap LOB app where programming style/syntax would be the highest barrier to entry. Even then I am suspicious. Anyways there's a lot of untalented developers that apparently cannot cope with FP, or much of anything really, and managers that are scared of different languages.
harigov 11y ago
I thought the idea behind .NET CLR was to make it easier to use whatever language makes sense for the problem without worrying about whether it can be integrated into the overall system. By making C# into a language for everything, MS isn't using strengths of .NET to its advantage. I would much rather learn 10 easy languages that work together than a single, complicated monster of a language that I can never wrap my head around (read C++).
- ygra 11y ago
  I'd argue that C# is still much simpler and easier to understand than C++. But in any case, one major problem with .NET and multiple languages in a single project is that a compilation unit is an assembly. So you can write one assembly in one language and another in a different language, but that's about the extent of being able to mix languages in a project. Which just may be not fine-grained enough.
  - tracker1 11y ago
    Not only that, but when you do mix languages in the same solution VS has a history if getting confused... I used to bring in VB.Net when I had to deal with a lot of XML after they added XML literal syntax (similar to E4X), but it was never added to C# (though LINQ was, go figure). In any case, it gets really messy.
  - titanix2 11y ago
    Actually assembly is the minimal unit of deployment, not compilation. The minimal unit of compilation is the netmodule[1]. You can compile from different languages as netmodules, then link the resulting netmodules together in an assembly. By the way, this is not a scenario supported by Visual Studio, so it requires using command line tools. So for any practical purpose, you're right that multi-language solution require the use of multiples assembly projects, which is tedious. [1] http://blogs.msdn.com/b/junfeng/archive/2005/02/12/371683.aspx http://blogs.msdn.com/b/junfeng/archive/2005/02/12/371683.as...
    - ygra 11y ago
junto 11y ago
This is probably a stupid question, but why do we have null as a concept? Nullable booleans especially grate on me. Surely it is true or false, but not null. Otherwise you surely have the wrong type? Does anyone else have these deep down feeling that null feels wrong?
- Athas 11y ago
  Null is wrong. It was implemented because it was easy, as it maps directly to how object references are typically implemented in memory: http://lambda-the-ultimate.org/node/3186 http://lambda-the-ultimate.org/node/3186
  - Sanddancer 11y ago
    That is null as a reference. Null as a type, however, is useful. An off the top of the head situation is suppose you have a ballot. On this ballot, one can vote for one of x, or they can choose to not vote for any at all. In verifying and tabulating the votes, having a null value makes a lot of the rest of the process easier.
- jasode 11y ago
  >Surely it is true or false, but not null. If that's surely what you have, then you have a regular "bool" and not nullable "bool?". In C#, "bool" and "bool?" are not the same type. (Although C# provides some convenient implicit conversions that minimize tedious verbosity when working with both -- but that convenience also has the effect of blurring the lines. Nevertheless, they are different types.) A "bool" can represent 2-states. A "bool?" can represent 3-states: true -or- false -or- unknown/empty/indeterminate/invalid/etc. Your premise that I quoted is constrained to 2 states -- therefore use the 2-state type which is plain "bool". Unless you think nullable "bool?" as a syntax seems to defy some kind of airtight mathematical logic? What would be the alternative?!? Have everyone create a custom enum that with 3 enum values "{falsy = 0; truthy = 1; unknown = 2}"? Why would reinvention of those semantics in everyone's redundant code snippets be better than C#'s standard nullable "bool?"? (Another issue that may confuse the "null" discussion is the 2 separate concepts of "null": #1 is "null" as an indicator of pointing to invalid memory and #2 is "null" as deliberate semantic placeholders for application/business logic of unknown values. The #2 concept is what is modeled by C# nullable<T> and SQL database fields.)
dep_b 11y ago
I always advocated for this kind of change in C# and now I'm using Swift I'm definitely sure that non-nullability should be available in any kind of OO-language. There aren't that many use cases that require nullability of a reference and there are many cases where the forced nullability bites you. Unfortunately adding it to C# now will mean that either the language breaks or the feature will be an add-on that isn't as powerful as it should be (like in Swift, where it's really the base for everything). Personally I would say that a reference type can be declared explicitly non-nullable with an exclamation mark (!) and if they're properties they either should have a default value or they should be set while the class is constructed.
jug 11y ago
I always liked Swift for the pragmatic solution to null reference issues, perhaps the most attractive aspect of that language to me, so this is nice to see!

84 points by Permit 11y ago

There is no way they can introduce a breaking change _this big_ into the language. This change effectively breaks almost every big piece of C# code.

mikko_m 11y ago
As described in the proposal, it's supposed to be an opt-in feature.
- inglor 11y ago
  It would be impossible to _actually_ have a feature like this as opt in since it would effectively create two different versions of C#. What the proposal does is emit warnings (and not errors) which is another shame. I'd much rather have it opt in at the class declaration level like: `strong class Foo` Where strong means references to it act like value type references with regards to nullability. Alternatively, they can just fork C# and remove all the weird parts they've accumulated over the years and stay with a sub-language that's more powerful and they can add useful features on top of.
  - jeswin 11y ago
    > would be impossible to _actually_ have a feature like this as opt in since it would effectively create two different versions of C# You still haven't said what's wrong with the proposal. There are multiple versions of C# already. Emitting warnings seems to be a good compromise, given there is already an option to treat warnings as errors. >`strong class Foo` This is a slippery slope. Next time they add another feature for correctness, they'll have to add 'stronger class'. This is akin to "use stricter" proposed by Sound Script (JS).
    - jaked89 11y ago
      In big codebases, warnings are useless. No one reads them. They usually contain thousands of items from different plugins, designers, etc. Sorting through them all is impractical. Errors are not just about protecting a developer from himself, but more importantly, protecting developers in a team from one another. If the compiler can't produce an error, the whole feature is pointless.
      - DrJokepu 11y ago
        I worked on some fairly large C# projects where the teams had zero-warning policies. It's not that difficult to achieve with a bit of discipline. Warnings in third-party dependencies only show up if you build them from source, but these days it's a lot easier to get your third-party dependencies from NuGet instead. That being said, I don't think warnings would be a good way to go on this case, because the sheer number of warnings generated by these new rules in existing, large (and mostly bug-free) projects would make it very difficult to reestablish a zero-warnings state. Developers on the team will just get undisciplined due the the broken windows effect.
        AndrewDucker 11y ago
        Yup. We have a zero-warning policy, and there's a setting in every project you can enable to treat warnings as errors, which we use.
      - Locke1689 11y ago
        Warn-as-error can be set for individual warnings as well as for every warning. However if your build is spitting thousands of warnings and no one cares, that sounds like an issue someone should be looking at...
    - Dylan16807 11y ago
      > You still haven't said what's wrong with the proposal. "The feature will not provide airtight guarantees, but should help find most nullability errors in code." That seems like a pretty big flaw, but it's still an improvement. And it's not exactly a slippery slope to add more kinds of strict. Here, have a syntax: use strict(a, b, c).
olavk 11y ago
I don't see what it will break? Sure you might get a lot of warnings if you upgrade (if I understand the proposal correct), but everything is going to work just as before.

DiabloD3 11y ago

I completely agree with this proposal, especially since this seems to be opt-in, otherwise a lot of "probably bug free" code would suddenly break. If this makes it into 7, a lot of code should at least be attempted to be converted to this to cut down on an entire class of bugs. Seriously, Microsoft is making me happy that they're taking the whole "languages should make the job of the programmer easier, not harder" thought process seriously.

jimktrains2 11y ago
I only used C# for a few months, a few years ago, but I immediately loved the language. I wasn't thrilled about the documentation (Why aren't return types listed in [1]?), VS (OK, vim key bindings made more bearable), or just dealing with the MS ecosystem in general, but I loved the language. It felt like everything Java was suppose to be, but is failing at. [1] https://msdn.microsoft.com/en-us/library/system.string%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/system.string%28v=v...
- mattmanser 11y ago
  Because it's a statically typed language it's all in the IDE. Almost everyone who uses C# doesn't need to check the documentation for that kind of information, it comes up when you're typing, or it's an ctrl-space away if your caret is on a method, or you can right-click go to definition. You can pretty much right click on anything and go to definition, which will show you all the method signatures and return types of everything. My only beef with the documentation is that they show examples of the code in use, but annoyingly never the output. So, for example, it's never clear even from the examples in the documentation whether a directory path or a URL includes a trailing slash or not. And because there's no REPL, you have to either build/compile/run or use an external program (I used to use some LINQ tester program that was basically a REPL, but it's contextually almost as expensive as simply trying it in an existing program).
  - Locke1689 11y ago
    > And because there's no REPL Working on it -- you can expect a public pre-release soon. The code is in master right now: https://github.com/dotnet/roslyn/tree/master/src/InteractiveWindow https://github.com/dotnet/roslyn/tree/master/src/Interactive.... I'll have to check with the dev to see how installing it is supposed to work, but he demo'd it on Friday and it looked very slick.

Maarten88 11y ago

I have not even started using C#6, which introduces the Null-Conditional operator. I expect this to already cleanup a lot of that verbose null-checking code, and avoid null reference exceptions simply because checking for null gets so much easier. To me, as a C# dev, this proposed change seems rather quick (let C#6 get some use first) and it also seems not consistent with nullable value types: with a reference type you'll get a compiler warning where the same error on a value type will give an error.

jasode 11y ago
>To me, as a C# dev, this proposed change seems rather quick (let C#6 get some use first) ... Not really. The non-nullable references feature request has been on the radar for many years. (E.g. this July 2009 stackoverflow post[1]). There are also some very old MS channel9 videos where Anders Hejlsberg acknowledged that the community wants this safety feature and discusses the difficulties of implementing it. I don't have a link to the video but this 2008 stackoverflow post mentions a Computerworld interview on the topic.[2] Non-nullable references is not a shoot-from-the-hip feature addition, and the C# team has been thinking about it for a very long time [1]http://stackoverflow.com/questions/411906/c-sharp-net-design-flaws http://stackoverflow.com/questions/411906/c-sharp-net-design... [2]http://stackoverflow.com/a/178090 http://stackoverflow.com/a/178090
CmonDev 11y ago
Two year release cycles are quick for you?
- Maarten88 11y ago
  No, but Visual Studio 2015 came out July 20, only 7 weeks ago. I've been using it 3 weeks now. I find it difficult to judge a proposed feature when there was so little time to get used to the current situation. Maybe it's a great idea, I don't know. It looks like the next step beyond the Null-Conditional operator. I'll be migrating a lot of code to use that in the coming weeks. After that I'll have a much better idea how much I like this idea.

MichaelGG 11y ago

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.

alkonaut 11y ago

While I think these C#7 proposals are all cool features (Non-null, tuples, pattern matching), it feels almost like it's too late to make improvements of this kind to C#. We have had F# for a very long time, do we really need non-null and pattern matching and so on in C#? The features sure make sense for C#, but do they make sense now? As more and more features come into C#, all of the BCL would have to be updated to use them if they are to deliver their full value. When generics entered in .NET 2.0, the generic and non-generic collections API were both included in the BCL, and they still are. I can't see how it would be as easy to make the BCL take full advantage of proper tuples, non-nullables etc., in a way that doesn't feel like a complete afterthought. I'm all for adding features, and I'd be happy to get breaking changes and update thousands of lines of code to get them. But I fear that isn't going to happen, instead things will come in as optional features, the BCL won't be updated to return tuples where it should (I.e. whereever it would have if the feature had been around forever), and so on.

AndrewDucker 11y ago
It might be too late to update the BCL with them. But that doesn't make it too late to bring the updates to people who work with C# all the time. I maintain a bunch of C# codebases, and I'd love to have more updates to the language.
MichaelGG 11y ago
Unfortunately, since people are dumb[1], we're stuck with C#. So they might as well improve it as much as possible. This feature could be layered on top of the BCL as extra metadata. Sorta like TypeScript allows you to add type annotations to third-party libraries, C# could take that approach with null. (Yes, this is sorta ugly.) With tuples, C# can take F#'s approach and special-case common patterns (like TryParse that use out parameters). There's probably only a few patterns where this matters and you'd get most of the benefit. (And I suppose you could always provide annotations to note how to match certain non-tuple-returning functions.) 1: There's really no reason to use C# when we have F#, unless the app is some crap LOB app where programming style/syntax would be the highest barrier to entry. Even then I am suspicious. Anyways there's a lot of untalented developers that apparently cannot cope with FP, or much of anything really, and managers that are scared of different languages.

harigov 11y ago

I thought the idea behind .NET CLR was to make it easier to use whatever language makes sense for the problem without worrying about whether it can be integrated into the overall system. By making C# into a language for everything, MS isn't using strengths of .NET to its advantage. I would much rather learn 10 easy languages that work together than a single, complicated monster of a language that I can never wrap my head around (read C++).

ygra 11y ago
I'd argue that C# is still much simpler and easier to understand than C++. But in any case, one major problem with .NET and multiple languages in a single project is that a compilation unit is an assembly. So you can write one assembly in one language and another in a different language, but that's about the extent of being able to mix languages in a project. Which just may be not fine-grained enough.
- tracker1 11y ago
  Not only that, but when you do mix languages in the same solution VS has a history if getting confused... I used to bring in VB.Net when I had to deal with a lot of XML after they added XML literal syntax (similar to E4X), but it was never added to C# (though LINQ was, go figure). In any case, it gets really messy.
- titanix2 11y ago
  Actually assembly is the minimal unit of deployment, not compilation. The minimal unit of compilation is the netmodule[1]. You can compile from different languages as netmodules, then link the resulting netmodules together in an assembly. By the way, this is not a scenario supported by Visual Studio, so it requires using command line tools. So for any practical purpose, you're right that multi-language solution require the use of multiples assembly projects, which is tedious. [1] http://blogs.msdn.com/b/junfeng/archive/2005/02/12/371683.aspx http://blogs.msdn.com/b/junfeng/archive/2005/02/12/371683.as...
  - ygra 11y ago

junto 11y ago

This is probably a stupid question, but why do we have null as a concept? Nullable booleans especially grate on me. Surely it is true or false, but not null. Otherwise you surely have the wrong type? Does anyone else have these deep down feeling that null feels wrong?

Athas 11y ago
Null is wrong. It was implemented because it was easy, as it maps directly to how object references are typically implemented in memory: http://lambda-the-ultimate.org/node/3186 http://lambda-the-ultimate.org/node/3186
- Sanddancer 11y ago
  That is null as a reference. Null as a type, however, is useful. An off the top of the head situation is suppose you have a ballot. On this ballot, one can vote for one of x, or they can choose to not vote for any at all. In verifying and tabulating the votes, having a null value makes a lot of the rest of the process easier.
jasode 11y ago
>Surely it is true or false, but not null. If that's surely what you have, then you have a regular "bool" and not nullable "bool?". In C#, "bool" and "bool?" are not the same type. (Although C# provides some convenient implicit conversions that minimize tedious verbosity when working with both -- but that convenience also has the effect of blurring the lines. Nevertheless, they are different types.) A "bool" can represent 2-states. A "bool?" can represent 3-states: true -or- false -or- unknown/empty/indeterminate/invalid/etc. Your premise that I quoted is constrained to 2 states -- therefore use the 2-state type which is plain "bool". Unless you think nullable "bool?" as a syntax seems to defy some kind of airtight mathematical logic? What would be the alternative?!? Have everyone create a custom enum that with 3 enum values "{falsy = 0; truthy = 1; unknown = 2}"? Why would reinvention of those semantics in everyone's redundant code snippets be better than C#'s standard nullable "bool?"? (Another issue that may confuse the "null" discussion is the 2 separate concepts of "null": #1 is "null" as an indicator of pointing to invalid memory and #2 is "null" as deliberate semantic placeholders for application/business logic of unknown values. The #2 concept is what is modeled by C# nullable<T> and SQL database fields.)

dep_b 11y ago

I always advocated for this kind of change in C# and now I'm using Swift I'm definitely sure that non-nullability should be available in any kind of OO-language. There aren't that many use cases that require nullability of a reference and there are many cases where the forced nullability bites you. Unfortunately adding it to C# now will mean that either the language breaks or the feature will be an add-on that isn't as powerful as it should be (like in Swift, where it's really the base for everything). Personally I would say that a reference type can be declared explicitly non-nullable with an exclamation mark (!) and if they're properties they either should have a default value or they should be set while the class is constructed.

jug 11y ago

I always liked Swift for the pragmatic solution to null reference issues, perhaps the most attractive aspect of that language to me, so this is nice to see!