> On Dec 4, 2016, at 2:40 PM, Robin Sommer <[email protected]> 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
> comparision.
+1
>> - 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.
- Jon
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
