Anonymous

My feedback

  1. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous commented  · 

    I suppose, this can be solved on a library level. I don't see a need to add this to the core language.

  2. 2,638 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    36 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
  3. 6,013 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    212 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous commented  · 

    @Paulo: Actually, your example is not correct: dereferencing null pointer in C++ is undefined behaviour, the program is not well-formed.

    Anonymous commented  · 

    @gzak: well, I won't point to the Spec# language which is able to enforce nun-nullable semantics, I'll point to a well-known example: C++. The C++'s references are basically the same as non-nullable references. So if C++ is able to cope with such a feature, why C# cannot be?

    Next, consider your example of MyMethod accepting string!. This has an equivalent right now, without non-nullable string: the documentation for the method may say that the string argument must be non-null. As a good citizen, you must either be sure that the string which you have is non-null, or you must check it before passing as argument. (You have a 3rd option of forgetting to check and getting a weird runtime exception though.)

    With the non-nullable strings, the first case (you are sure that string is not null) will be explicitly expressed by the former string having static type string! instead. The second case with runtime check will be unchanged: now you need it not for satisfying the requirement, but for converting string into a string!. (The third case is however not possible, which is a clear advantage.)

    Note that each string literal is itself a string!, so you'll just need to propagate the new type, switching from implicit logical condition in your program (some variables here and there may not be null) to explicit ones. The operations on strings and system functions known to return a non-null string can be automatically un-lifted by the compiler.

    Next, about solving the problem with division. Basically you are right in noticing that problem of invalid operations may be solved with a more strict type system. However introducing a non-zero int seems for me too big change for too small gain, and that is the only reason it's not suggested elsewhere.

    P.S.: I've already given my vote for safe navigation operator.

    Anonymous commented  · 

    @Kris: me either :) After some digging, it's not Cω, it's Spec#. The project page (http://research.microsoft.com/en-us/projects/specsharp/) says that Spec# is an extension of C# "with constructs for non-null types, preconditions, postconditions, and object invariants".

    Anonymous commented  · 

    @Kris: you can see it like the feature in C++, where you can have arrays of (and use dynamic_cast with) pointers, but not references [which bear some resemblance to nullable and non-nullable reference types in C#].

    Anonymous commented  · 

    @Kris: the question boils down to implementation of default(T) for a non-nullable T.

    My personal opinion would be making it just illegal, so it wouldn't be possible to have an array of C!'s. So, as a direct answer to your question, this shouldn't be compilable.

    This would make an unpleasant difference between "natively" non-nullable value types and nullable reference types, however I don't see any better solution.

    Interesting is, how is this implemented in Comega (http://research.microsoft.com/en-us/um/cambridge/projects/comega/)?

    Anonymous commented  · 

    @Marc: Well, I don't think this brings too much of additional complexity into the language. On the contrary, it makes the type system simpler: with your suggestion, both reference and value types can be either nullable or not. As of now, only value types have a choice.

    Anonymous commented  · 

    @Akash: Well, are the Code Contracts constraints enforced at compile-time? If no, your suggestion doesn't bring too much.

    Anonymous supported this idea  · 
  4. 268 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    11 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous commented  · 

    A different but connected good addition could be the following syntax:

    Tuple<int, char> f() { ... }
    int n, char c = f();

  5. 217 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    8 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
  6. 146 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  Visual Studio IDE » .NET  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
  7. 277 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Visual Studio IDE » .NET  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 

Feedback and Knowledge Base