[Bro-Dev] [Proposal] Language extensions for better Broker support
jsiwek at illinois.edu
Tue Dec 6 12:43:06 PST 2016
> On Dec 4, 2016, at 2:40 PM, Robin Sommer <robin at icir.org> wrote:
> "(v as T)$foobar” vs "as<T>(v)$foobar”.
Could just do some time trials to see which one people can type faster. There’s online typing speed tests that let you enter the test’s text. I consistently typed "(v as T)$foobar” faster.
>> Is there a reason "type(v)” can’t be stored?
> Mind elaborating how you would expect to use that?
Was thinking I’d end up doing something like (more a personal habit/style thing):
local t = type(v);
if ( t == count )
else if ( t == int )
But this example came to mind only because the draft didn’t have “v is T”. Point seems moot now.
> seems the existing switch could just infer that it's maching types by
> looking at case values: if they are types, it'd use "is" for
>> - In the switch statement, I would require that a user either provide
>> a default case or fully enumerates all cases. Otherwise it's too
>> easy to cause harder-to-debug run-time errors.
> Are we requiring "default" for the standard switch statement? If so, I
> agree it makes sense to do the same here (otherwise, not so sure,
> because of consistency).
The “default" case is optional. If it were required, I wouldn’t feel safer — maybe I don’t frequently make/see mistakes related to that and/or don’t find them hard to debug.
More often I’ve seen forgotten “break” at the end of a cases causing unintentional fallthroughs, but Bro does require explicit “break” or “fallthrough” statement to end cases.
More information about the bro-dev