On Fri, Mar 31, 2017 at 6:20 PM Michael Jones <michael.jo...@gmail.com> wrote:
> I recalled it i the sort case because I wanted to kinds of typed clients for "<", the kind where !Less(a,b)&&!Less(b,a) === Equal(a,b), and the kind where that is not the case--and ideally--a way to have instantiation for the first kind use path A and the second kind use path B. That would have made the code truly general. I've been thinking about this for some <https://github.com/cznic/browse/blob/9c708378b88df1b3e968477a86d8144435d5f3d3/internal/gc/testdata/errchk/issue15292/0.go> time <https://github.com/cznic/browse/blob/9c708378b88df1b3e968477a86d8144435d5f3d3/internal/gc/testdata/parser/parser.y#L139> and the idea how to solve this particular issue goes like this: func Less<T>(a, b T) bool { switch x := a.(type) { case *float32, *float64: return !math.IsNaN(a) && !math.IsNaN(b) && a < b default: return a < b } } The point is that the type switch goes away completely when the [future] compiler sees the type-specialized version and can infer which case path will be taken. Of course, the current compiler rejects .(type) for non-interface types. -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
