3 ms·

Not disagreeing - can you explain a scenario where this helped so we can all understand how it is better than dealing with nulls in C#?

DontGiveTwoFlux 10y ago
I'm working on a big c# app right now. All over the code base are areas where we always assumed a call to .first() would always return at least one thing. The business needs have changed and now we have use cases where we return nothing. I've been playing a game of hunting down the many little areas where this could crop up. I can imagine that in f# this refactor would be a lot simpler and would allow me to have a case of empty that I could propagate around and handle transparently.
- sickbeard 10y ago
  How would functional programming help you in this department?
  - piaste 10y ago
    In C#, null is just one possible value of the regular type Foo. The compiler cannot tell whether you have started returning null where you previously only returned non-null values, nor can it tell whether you've handled those null values correctly at the consumption site. In F#, None is a subtype of the Option<Foo> union type, which is different from the plain Foo type and from the other subtype Some Foo. If you change a function that used to return a plain Foo into one returning Option<Foo>, every place in your code where that function is consumed will throw a compile error until you edit it to unwrap and handle the distinct Some Foo and None subtypes.
  - actsasbuffoon 10y ago
    Many functional programming languages have stronger type systems than C#. They typically don't accept null as a valid substitute for any type. To represent a nullable type, you wrap the value in a generic container. Think of it as being like an array that contains at most 1 item. The interface of this generic container only allows you to interact with the (potentially) wrapped value in a way that is type safe. That doesn't completely eliminate having to think about how the business logic should differ for missing values, but it ensures that you'll never get a null pointer exception.
dgudkov 10y ago
There is no way (from a type perspective) to guarantee in C# that an instance of a class can never be null -- this has to be ensured by code logic, conventions, etc. As application gets bigger it becomes easy to overlook a case that leads to a null reference exception. The type system in F# can guarantee that an instance of a class can never be null and you can always refer to it safely.

DontGiveTwoFlux 10y ago

I'm working on a big c# app right now. All over the code base are areas where we always assumed a call to .first() would always return at least one thing. The business needs have changed and now we have use cases where we return nothing. I've been playing a game of hunting down the many little areas where this could crop up. I can imagine that in f# this refactor would be a lot simpler and would allow me to have a case of empty that I could propagate around and handle transparently.

sickbeard 10y ago
How would functional programming help you in this department?
- piaste 10y ago
  In C#, null is just one possible value of the regular type Foo. The compiler cannot tell whether you have started returning null where you previously only returned non-null values, nor can it tell whether you've handled those null values correctly at the consumption site. In F#, None is a subtype of the Option<Foo> union type, which is different from the plain Foo type and from the other subtype Some Foo. If you change a function that used to return a plain Foo into one returning Option<Foo>, every place in your code where that function is consumed will throw a compile error until you edit it to unwrap and handle the distinct Some Foo and None subtypes.
- actsasbuffoon 10y ago
  Many functional programming languages have stronger type systems than C#. They typically don't accept null as a valid substitute for any type. To represent a nullable type, you wrap the value in a generic container. Think of it as being like an array that contains at most 1 item. The interface of this generic container only allows you to interact with the (potentially) wrapped value in a way that is type safe. That doesn't completely eliminate having to think about how the business logic should differ for missing values, but it ensures that you'll never get a null pointer exception.

dgudkov 10y ago

There is no way (from a type perspective) to guarantee in C# that an instance of a class can never be null -- this has to be ensured by code logic, conventions, etc. As application gets bigger it becomes easy to overlook a case that leads to a null reference exception. The type system in F# can guarantee that an instance of a class can never be null and you can always refer to it safely.