On Mon, Dec 22, 2014 at 8:45 AM, Huan Du <reald...@gmail.com
>> I'm somewhat sympathetic to this feature but it's troubling that it
> would make code like this valid:
>> f := float64(_) / _
> I'm aware of this kind of ill formed code. I don't like it either. So at the
> end of the document, I propose to use blank identifier as zero value in very
> limited set of expressions/statements and disallow using "_" with any
> I think it's possible to define some simple rules to avoid abuse - just like
> what I proposed.
Yes, but then I would describe it as non-orthogonal. It introduces a
totally new concept: the areas of Go where _ is permitted. That is a
comprehension cost--something else that people need to understand when
writing Go code. I don't think that is a good thing. I think that if
this is introduced it needs to be the same as nil: it's OK anywhere
that the type can be inferred. It's already annoying that we need
special cases for nil in the spec.