4 ms·

Can you explain more about what you mean by Swift allowing nil weakening it's type system? Swift types don't allow nil but you can use a different type that is

Can you explain more about what you mean by Swift allowing nil weakening it's type system? Swift types don't allow nil but you can use a different type that is the optional counterpart. This is just the same as using the Maybe monad in Haskell and can be reimplemented in that way. Do you think that this also weakens Haskell's type system? Now if your issue was with the "!" Operator I would say that there is a case to be made but that should be used sparingly and carefully and is an obvious place for additional code review.

the_af 12y ago
Hmm, maybe Swift's Optional works differently to Scala's Option, in which case my objection can be dismissed. In Scala, you can declare a value to be of type Option[T], which means it will be either a Some[T] or a None. This looks superficially like Haskell's Maybe monad. val x: Option[Int] = Some(1) The problem with Scala is that you can also write something like this: val x: Option[Int] = null By declaring a value to be of type Option[T], you "promise" it won't be null, but this is not enforced by the compiler. It's obvious this is a huge difference from Haskell's Maybe, and it weakens Scala. Null shouldn't even be part of Scala, but it's still there to retain compatibility with Java. Can a similar example be written with Swift? I assumed it was possible, but maybe I'm mistaken.
- josephlord 12y ago
  In Swift nil is the value equivalent to Haskell's None so there is no distinction there which I think you are saying that there is in Scala. Swift does have "implicitly unwrapped optionals" which you declare with "!": var x:Int! = nil rather than normal optional syntax of var x:Int? = nil It does weaken the type system and I would only make very limited use of it. I would only ever use it for properties that will not be nil after the initialiser has finished. Even though there is a way around the type system to do dangerous things I think it is still far better to have the type system there and to only work round it when absolutely necessary than to default to something much weaker. As I've mentioned elsewhere "!" is a code smell and I would use it rarely and audit those places heavily.

the_af 12y ago

Hmm, maybe Swift's Optional works differently to Scala's Option, in which case my objection can be dismissed. In Scala, you can declare a value to be of type Option[T], which means it will be either a Some[T] or a None. This looks superficially like Haskell's Maybe monad. val x: Option[Int] = Some(1) The problem with Scala is that you can also write something like this: val x: Option[Int] = null By declaring a value to be of type Option[T], you "promise" it won't be null, but this is not enforced by the compiler. It's obvious this is a huge difference from Haskell's Maybe, and it weakens Scala. Null shouldn't even be part of Scala, but it's still there to retain compatibility with Java. Can a similar example be written with Swift? I assumed it was possible, but maybe I'm mistaken.

josephlord 12y ago
In Swift nil is the value equivalent to Haskell's None so there is no distinction there which I think you are saying that there is in Scala. Swift does have "implicitly unwrapped optionals" which you declare with "!": var x:Int! = nil rather than normal optional syntax of var x:Int? = nil It does weaken the type system and I would only make very limited use of it. I would only ever use it for properties that will not be nil after the initialiser has finished. Even though there is a way around the type system to do dangerous things I think it is still far better to have the type system there and to only work round it when absolutely necessary than to default to something much weaker. As I've mentioned elsewhere "!" is a code smell and I would use it rarely and audit those places heavily.