Post by Michal MoskalPost by Sandro Magi1. It's less type-safe: an unintended object reference might escape
since everything can be implicitly cast to "object". This reduces the
type safety when composing functions and values, as in parser
combinators (I have a C# parser combinator library based on FP# for
instance). A "Unit" struct can only be cast to object, so if we never
use object as a parameter, we know that the code will not have runtime
type errors and will not require runtime type checks (as long as we
avoid other techniques that require type checks, like reflection).
I don't quite get it: you need an explicit cast to cast from the
object type anyhow.
Yes, *from* the object type, but not *to* the object type. This is what
I meant by a wrong type inadvertently escaping with no type error.
"returnNothing" should be "int -> unit", such that no object ref escapes
the closure; MySpecialObject is an object you don't want exposed to
client code. Fun<T,U> is part of my FP# library.
Compare:
MySpecialObject x = ...;
Fun<int, object> returnNothing = delegate(int i) {
/* some complicated code */
return x; //no type error, succeeds
}
MySpecialObject x = ...;
Fun<int, Unit> returnNothing = delegate(int i) {
/* some complicated code */
return x; //type-error
}
I was saying that having an empty Unit struct is less error-prone
because nothing can be implicitly cast from OR to Unit, and if you have
to return an instance of Unit, who cares? Unit doesn't carry any state,
it's just an empty struct. The code is ensured safe at compile-time.
Post by Michal MoskalPost by Sandro Magi3. Nullable values are just less safe overall. I'm wary of using null
anywhere for obvious reasons I think.
I guess in this case the compiler would be able to ''prove'' that the
returned null would not be used anywhere.
Anyhow, I don't mind using something else, maybe except that you're
forcing program to link to Nemerle.dll once they use this feature.
My FP# library is C#-only, I was just pointing out the approach I used
for safety reasons. Returning object when you want a unit type just
isn't as safe as having an explicit void/unit type. Since we can't use
.NET's void type, I added my own Unit type.
Sandro