I *think* I like having left out explicit returns and implicitly
returning self, in favor of implcitly returning the value of the last
statement. It unifies methods and blocks in a way I find pleasing.
However, my hand was somewhat forced here by Javascript semantics.
The only way to implement them (that I can think of) would be to throw
an exception, which would get caught and rethrown at every level up
the stack frame until it found the right one. �I don't want to do this
to the poor VM. �I've provided a "self return: [:returnBlock | ...]"
primitive that provides this when you really need it, but I've found
it's rarely used.

[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-September/139196.html

On 15 September 2011 07:01, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:

Hi

this is early (at least to me) and I was asking myself a probably stupid question. But I would like to get your smart answers :)

does a smalltalk like language really need explicit return in []?

Q1 When are they absolutely required?
Q2 What replacing mechanisms would be needed?
Q3 What would we gain from an implementation stand point?
It seems that in resilience lars removed them and more.

Stef

for Q1 I see

foo
� � � �x isZero ifTrue: [^ 33].
� � � �self continue