For 2, out of curiosity. What is wrong with the following code using math.MaxUint32 for instance:
https://play.golang.org/p/pPFvo1pOlc math defines a constant, which you will need to assign to an variable. But I don't see there being any type conversion in this piece of code. It is all implicit over the types given. Did you allude to something else? For 1, your workarounds are: * Write the code yourself by hand. The work seems tedious, but one observation I have from implementing monomorphisation/defunctorisation passes in compilers is that often the number of variant uses of an abstraction is at most a handful. Even in very large programs. So there may be less code to write in the common case than what people think. * Use a generator and generate the code. Essentially running the monomorphisation yourself as a first stage in the compiler. This is also pretty easy to do. A side note: if you *really* care about your programs efficiency, you need a compiler which supports staged compilation, so you can stage code generation for more than just types. For instance by specializing matrix multiplications to a specific dimension and so on. This is the land of cogen as well. On Fri, Jan 13, 2017 at 4:03 PM Ian Lance Taylor <i...@golang.org> wrote: On Fri, Jan 13, 2017 at 6:47 AM, hui zhang <fastfad...@gmail.com> wrote: > Yes , cycle import is a bad design. > But as the software becomes larger , not everything is controllable. > In real project , some times it is a great risk to do refactor. Go is careful to initialize values in the correct order, such that if the initializer for V1 refers to V2, then V2 is always initialized before V1. It is possible to break this by calling between packages in the initializers, but it takes a fair amount of work. If Go permitted cyclic imports, correct initialization would be impossible. Go has given up one feature (cyclic imports) in favor of another one (simple and correct initialization). Ian -- 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. -- 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.
