[nem-en] void as type parameter

[Sandro Magi]

Michal Moskal wrote:
> On 7/3/07, Sandro Magi <smagi at higherlogics.com> wrote:
>> That approach seems less-desirable for three reasons:
>>
>> 1. 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.

>> 3. 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