[nem-en] void as type parameter

[Sandro Magi]

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

2. Efficiency: I wonder if "new object()" returns a singleton, or
allocates a new heap object every time. I would guess the latter. Might
as well just use a stack allocated value, but I'll have to run some
simple benchmarks soon to see what the impact actually is.

3. Nullable values are just less safe overall. I'm wary of using null
anywhere for obvious reasons I think.

I haven't focused much on efficiency in the FP# library; the focus has
been more on safety.

Sandro

Michal Moskal wrote:
> One can as well use Object and pass null. I guess the overhead would
> be similar. This is actually what we have done some time ago, but I
> guess there were some cases where it didn't work, so Dimitry comitted
> a patch to just disallow it. Investigating this further is on my TODO
> list, but it somehow cannot get to the top...
> 
> On 7/1/07, Sandro Magi <smagi at higherlogics.com> wrote:
>> Yes, which is why I just created the empty "Unit" struct as a
>> pseudo-void type to fake it. :-)
>>
>> Sandro
>>