It's interesting how different people have different intuitions on semantics here. I also see it as consistent with function arguments, that's why I'd be fine it. That said, I was also thinking along the same lines of adding explicit capture specifications: deprecate the current, capture-spec-less syntax, and generally just require people to list what they want to capture; seems like a useful practice to me. And then we let them tell Zeek if they want deep or shallow copies (but always copies, not references). "when" could then move into the same direction as well; maybe it could even change to take a lambda instead of its own body. That would simplify the implementation, too.
Robin On Thu, Dec 10, 2020 at 09:40 -0800, Vern Paxson wrote: > > for sure on my wishlist is consideration for some deprecation-path, > > differentiating-syntax (maybe event just temporary), or other > > warning/notice that can help users along instead of potentially > > breaking their code outright. > > Good point. Seems a natural way to do this is to add C++-style [] capture > syntax, and a deprecation warning (and the current semantics) if it’s > missing. (And maybe no warning if the body doesn’t use any of the outer > variables, since that form will continue to work.) > > — Vern > _______________________________________________ > zeek-dev mailing list -- zeek-dev@lists.zeek.org > To unsubscribe send an email to zeek-dev-le...@lists.zeek.org -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
_______________________________________________ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
