I like this idea, including just deprecating the old syntax - that makes
it explicit what exactly happens.
Johanna
On 10 Dec 2020, at 18:06, Robin Sommer wrote:
It's interesting how different people have different intuitions on
semantics here. I also see it as consistent with function
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
There's also some weirdness with the current implementation:
Urp. Yeah, things get wonky in the current implementation when the
original outer function exits. (Your example works as expected if we
move the `zeek_init` statements into `demo`.) There’s a bunch of code
in that case to salvage
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 []
There's also some weirdness with the current implementation:
This outputs 4 & 5 like i'd expect:
function demo(): function()
{
local i = 3;
local f = function() { ++i;print i; };
return f;
}
event zeek_init()
{
local d = demo();
d();
d();
}
but this
On 9 Dec 2020, at 22:28, Vern Paxson wrote:
I agree with Johanna that whatever is done, it would be best if it
were consistent, and not vary with the type of the captured variable.
It already varies with type of variable for assignments and function
call parameters. Thus I’m puzzled at the
