4 ms·

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).