Thomas Leonard | 20 Oct 2011 14:12
Picon
Favicon
Gravatar

easy-when-binds-return

People often try to use return inside when blocks. Currently, this just 
produces confusing "Ejector must be enabled" errors.

How about requiring the use of "return" to return a value from a when block?

There are a few places where this would be useful:

- Often you will move a whole block in to or out of a when() block. It's 
useful if you don't have to change all return lines when you do this.

- People sometimes don't notice that the value of the last expression is 
used, and put something after it.

e.g. they change

return when (foo) -> {
	foo.invoke()
}

to

return when (foo) -> {
	foo.invoke()
	traceln("here")
}

and then wonder why they're getting null pointer exceptions elsewhere.

- You can accidentally return a value, when all you intended was to tell 
the caller when you were done.
(Continue reading)

Kevin Reid | 20 Oct 2011 14:59
Favicon
Gravatar

Re: easy-when-binds-return

On Oct 20, 2011, at 8:12, Thomas Leonard wrote:

> People often try to use return inside when blocks. Currently, this just 
> produces confusing "Ejector must be enabled" errors.
> 
> How about requiring the use of "return" to return a value from a when block?

No.

We used to do that (along with otherwise treating the when-block more like a function), and decided it was
too heavyweight and confusing. This makes 'when' more like other control structures. In particular, it
is more like the user-defined control structures of the "lambda-args" pragma; we *expect* to find more
"eventual control structures" to want.

I will not support any change to 'when' which moves it farther from the semantics expressible by lambda-args.

I am also against making E more 'imperative style' given that it's not going to stop being a hybrid.

--

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>

Gmane