Yeah i see, but in my understanding it is not blocking, you are currently repeating a dogmatic mantra.
That you declare a var ctx should override the meaning of ctx in following expressions, in such call `ctx call.expr()` there s absolutely no way to mistake about the meaning of ctx, it must be a keyword, not a var. in `xx:= ctx.get()` ctx meaning is guessed after analysis. One thing that might be troublesome is, if you go further and say you might want to start a named context, such as `ctx.named(...) call.expr()` because it is two following expr without semi/nl. please consider. On Saturday, April 15, 2017 at 9:37:09 AM UTC+2, Viktor Kojouharov wrote: > > Adding a new keyword would break backwards compatibility > > On Saturday, April 15, 2017 at 10:21:32 AM UTC+3, mhh...@gmail.com wrote: >> >> hi, >> >> >> The question is in the title, >> >> the rationale, all the changes needed to apply on the source code to a >> add context as a parameter. >> >> We may imagine a ctx as a special keyword, where `ctx hello()` would >> arrange hello body (and so forth recursively) to insert ctx.Done call >> appropriately (as much as possible, maybe at regular tick ? or just insert >> calls into the ast) >> and to get the ctx have a ctx.get() special keyword, if needed. etc >> For the return arguments, it could generate automatically the appropriate >> default values for the func signature currently ctxed and a special error >> value for a ctx.done (again it needs some analysis of func signature, just >> some implementation details). >> >> Just wonder. >> >> >> thanks >> > -- 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.
