I'm not convinced there is a "why" other than "that's what happens". Feel free to file an issue.
-rob On Wed, Jun 22, 2016 at 1:29 PM, Evan Digby <evandi...@gmail.com> wrote: > Hi Rob, > > Thanks! I'm using 1.6. I guess my question wasn't too clear now that I > read it back. > > The question isn't why I can redefine. More specifically, my question is > why redefining by parsing an empty string returns an error on Execute. > > Why can't we redefine a template as empty string? If that's expected, why > would it not return an error when parsing and not executing? > > I think the "same base template" info from my original post is a red > herring, because I imagine it's not "redefining" if they're not part of the > same tree somehow. > > Thanks again, > > Evan > > On Wednesday, 22 June 2016 13:22:09 UTC-7, Rob 'Commander' Pike wrote: >> >> You don't say what version of Go you are running, but as of Go 1.6, >> templates can be redefined, which supports the new 'block' feature. >> >> You are redefining a template, which used to be an error but is not any >> more. >> >> -rob >> >> >> On Wed, Jun 22, 2016 at 1:13 PM, Evan Digby <evan...@gmail.com> wrote: >> >>> I'm noticing that if I accidentally create a second template with the >>> same name but no content there is no error reported when I "parse" it, but >>> then when I attempt to execute it I do see an error: >>> >>> https://play.golang.org/p/Rj3433vvju >>> >>> Is this expected behaviour? Why wouldn't it simply return an error from >>> the Parse call? >>> >>> The key is the second template must have no content. The following does >>> not return an error on execute: >>> >>> https://play.golang.org/p/O5xv5rS-cg (both have content) >>> https://play.golang.org/p/kaoVWRunrP (only the second has content) >>> >>> I have also noticed that this isn't an issue if they are not all based >>> from the same template: >>> >>> https://play.golang.org/p/iLoHokX4uy >>> https://play.golang.org/p/T07Z9rvfmW >>> >>> The inconsistency in behaviour between the examples listed is a bit >>> confusing. If there truly is expected that the one case that does error our >>> on execute should error out, and not the others, I believe that the error >>> makes more sense (and could be easily caught) on the Parse call, not the >>> execute call. >>> >>> Can someone provide some insight into why this might legitimately be >>> behaving this way? >>> >>> Thank you! >>> >>> >>> >>> >>> -- >>> 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...@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. > -- 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.
