RE: [Xen-API] [PATCH] imported patch removing-warnings

[Rok Strnisa <rok.strnisa@xxxxxxxxxx>]

Hi Vincent,

> But, you are introducing future hard-to-find bugs. if nothings change
> since last i look, partial applications warning are enabled as error
> (they are really the nastiest kind of errors).
> 
> when using let _ = .. you're explicitely telling the type system, that
> you don't care what the value is. as such it can't treat a unused
> partial application as a problem, because you're explicitely told him
> to
> ignore it. Hence in the future if someone add arguments to some
> function
> that happens to be on the right side of the let (_) = .., suddenly the
> value becomes of type "a -> b" instead of "a", which because of the let
> _ binding will be ignored (and because it's partial, the function is
> not
> applied, and possible side effects are then missing).

My patch did not introduce any future hard-to-find bugs, since any change of 
the type you describe above would still have been silently ignored by the 
compiler even without the change.

> This is why you need to type your ignored let binding with a let (_ :
> type expected) if you want to fix the warning *properly*.
> 
> as a convenience there is a ignore_{int|string|...} in
> stdlib/pervasiveext for common type that can be ignored.

I agree that this is a better approach, but also much more time-consuming. I 
think it's worth re-emphasizing this:

> > This patch is in fact only a start of removing the sea of warnings
> that get generated while compiling xen-api.hg. Currently, there are so
> many warnings that nobody pays attention to them any more, or notices
> that they generated a new one --- the whole purpose of warnings is lost.
> The goal is to reach zero warnings, and then enable the warnings-as-
> errors flag.
> >
> > Therefore, I think the patch is safe as-is, but feel free to remove
> assignments you are definitely sure don't give side-effects _and_ were
> not meant for something else.

Because this will take some effort, I've decided to not do it all myself, but 
rather use the source control to identify who is responsible for each warning, 
and delegate it to them --- originally an idea by Jonathan Knowles.

Regards,
Rok

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api