[Bro-Dev] [Proposal] Language extensions for better Broker support

[Siwek, Jon]

> 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
> 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