i thought i remembered, a few releases back, that the go compiler started doing wider ranging analysis that allowed it to optimise and do some low level dead code elimination?
if so, wouldn't that mean that any extra blank-return 'clones' would potentially be able to be compiled with more code eliminated? (including the actual assignment.), and if you knew this was happening you could write source in a way to allow more of it, as an optimisation. OTTOMH how about an int division with the second returned value the remainder. On Tuesday, 22 January 2019 00:00:47 UTC, Ian Lance Taylor wrote: > > On Sun, Jan 20, 2019 at 2:44 PM 'simon place' via golang-nuts > <golan...@googlegroups.com <javascript:>> wrote: > > > > wouldn't the compiler be able to use the fact that a return value is > known not to be being used in a particular call, somewhere one or more of > the returned values are assigned to a blank, to be able to generate faster > code for that call? > > > > or is it already being done? because, it seems to me, knowing if it was > would effect how you might lay out a function and even promote some novel > patterns. > > I don't see how this would help with a particular call, other than > making a clone of the function that omits one of the results. If the > function is unchanged, it's going to compute all the results anyhow. > And an ignored result will simply be ignored. An assignment to the > blank identifier doesn't cause any code to be generated. > > 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.
