[nem-en] incorrect side effect of ++ operator

[Michal Moskal]

On Mon, Sep 27, 2004 at 02:32:53PM +0200, Kamil Skalski wrote:
> Probably you are right, that this is conterintuitive for C programmer. I also 
> liked the semantics of tab [i++] = 5;
> 
> But in functional language it is better to keep assignments having type void.


Well, this is more related to partial application. Consider following ML
fragment:

  let foo x y = ... in
  ...
  foo 3;
  ...

Now the OCaml compiler will report warning about unused computed value,
which prevents severe bug of not calling foo at all. This is why the
unused value warning is so crucial there.

However this kind of bug is not possible in Nemerle -- we use () for
function all, so it would be a typing error to write:

  def foo (x, y) { ... };
  ...
  foo (3);
  ...

So it is to be reconsidered whether to make unused value warnings
optional. In fact this warning have never prevented me from making
any mistake.

Now, when the warning is optional, we can make ++ return value, there
is no problem with that. We could even make = return value, but I would
rather avoid this one (if (x = true) ... vs if (x == true) ...).

Another thing to reconsider is the if/when/unless issue, maybe there
should be just if. But I'm not sure about this one.

> BTW. it is strange that WriteLine works with void overload. I'm pretty sure it 
> shouldn't and it's problably a bug, that we allow it.
> 
> void shouldn't be subtype of object

But it is. *Every* type is subtype of object. Period. This is the .NET
understanding of type system. We can do nothing about it. We should be
happy, that it is supertype of everything, since our encoding of 'a ->
'b functions would not work for int -> void otherwise.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?