5 ms·

Still hoping they add the !(non-nullable) operator. I know its hard http://blog.coverity.com/2013/11/20/c-non-nullable-reference-types/#.VGY_5fnF-QA http://blo

Still hoping they add the !(non-nullable) operator. I know its hard http://blog.coverity.com/2013/11/20/c-non-nullable-reference-types/#.VGY_5fnF-QA http://blog.coverity.com/2013/11/20/c-non-nullable-reference... But dang I would appreciate it. So much code is cluttered with null checks that increases the robustness of the code at the cost of correctness, readability, and poorly defined behavior.

pjungwir 12y ago
In my limited C# experience I found `int?` to be really nice, and an operator to non-null it sounds even nicer. I wonder if there is any chance of Rust getting an abbreviation like `?` so you can write `int?` instead of `Option<int>`. I'm just starting to explore the language, but it seems like a lovely addition.
- mytochar 12y ago
  Rust's syntax has actually been getting more wordy and less variable-y. At least, that's what happened when the changed around Box and some other syntax-sugar'd variables. I wouldn't expect Rust to go back to shorthand after leaving it.
- bjz_ 12y ago
  Rust is trying to reduce the amount of magic in the libraries as much as possible. This means that whatever the language/standard library authors have available to them, third party library authors should also have access to. `T?` would probably run against that, given the previous removal of `@T`, `~T`, `~T`, and `~str` in favor of `Gc<T>`, `Box<T>`, `Vec<T>`, and `String`.
Someone1234 12y ago
Aren't you just shifting the problem rather than solving it? For example, let's say I am calling a function which returns an object: var myStuff = new GiveMeStuff().GenerateStuff(1337); The return of this value can be valid "stuff," an exception, or null. If we remove null as an option, what happens when internally an exception is thrown within GenerateStuff()? Does it re-throw that exception? Or do we now need a property within stuff like (bool)myStuff.validStuff? Null is a very useful way of communicating something failed. It is useful firstly because it is a "cheap" comparison and secondly because it saves us from having to place try{}catch(){} blocks around all of the things. So my question is: without null how are we communicating failure? More exceptions? Or more clutter within our objects.
- bmm6o 12y ago
  Null values don't go away, it's just that reference types aren't by default nullable. Your function can still return null (if you really want it to) as long as that is indicated by the return type. What you can't do is directly assign the possibly null return value of your function to a non-nullable reference.
- bjz_ 12y ago
  Languages like Haskell, Swift, and Rust use an optional type[0] for nullable things. Most things don't need to be nullable, and by being explicit about it in your type you convey your intent - ie. 'this thing might fail, and you must handle it if it does'. - [0]: http://en.wikipedia.org/wiki/Option_type http://en.wikipedia.org/wiki/Option_type
- coldtea 12y ago
  You might want to read this: http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare http://www.infoq.com/presentations/Null-References-The-Billi...

pjungwir 12y ago

In my limited C# experience I found `int?` to be really nice, and an operator to non-null it sounds even nicer. I wonder if there is any chance of Rust getting an abbreviation like `?` so you can write `int?` instead of `Option<int>`. I'm just starting to explore the language, but it seems like a lovely addition.

mytochar 12y ago
Rust's syntax has actually been getting more wordy and less variable-y. At least, that's what happened when the changed around Box and some other syntax-sugar'd variables. I wouldn't expect Rust to go back to shorthand after leaving it.
bjz_ 12y ago
Rust is trying to reduce the amount of magic in the libraries as much as possible. This means that whatever the language/standard library authors have available to them, third party library authors should also have access to. `T?` would probably run against that, given the previous removal of `@T`, `~T`, `~T`, and `~str` in favor of `Gc<T>`, `Box<T>`, `Vec<T>`, and `String`.

Someone1234 12y ago

Aren't you just shifting the problem rather than solving it? For example, let's say I am calling a function which returns an object: var myStuff = new GiveMeStuff().GenerateStuff(1337); The return of this value can be valid "stuff," an exception, or null. If we remove null as an option, what happens when internally an exception is thrown within GenerateStuff()? Does it re-throw that exception? Or do we now need a property within stuff like (bool)myStuff.validStuff? Null is a very useful way of communicating something failed. It is useful firstly because it is a "cheap" comparison and secondly because it saves us from having to place try{}catch(){} blocks around all of the things. So my question is: without null how are we communicating failure? More exceptions? Or more clutter within our objects.

bmm6o 12y ago
Null values don't go away, it's just that reference types aren't by default nullable. Your function can still return null (if you really want it to) as long as that is indicated by the return type. What you can't do is directly assign the possibly null return value of your function to a non-nullable reference.
bjz_ 12y ago
Languages like Haskell, Swift, and Rust use an optional type[0] for nullable things. Most things don't need to be nullable, and by being explicit about it in your type you convey your intent - ie. 'this thing might fail, and you must handle it if it does'. - [0]: http://en.wikipedia.org/wiki/Option_type http://en.wikipedia.org/wiki/Option_type
coldtea 12y ago
You might want to read this: http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare http://www.infoq.com/presentations/Null-References-The-Billi...