You have a valid point. Though from a user's point of view, I'd say using a relatively quick but non-optimal implementation has the benefit of testing it in action sooner and making sure it doesn't have side-effects or doesn't introduce backward incompatibility.
On 5 October 2017 at 08:30, Paul King <pa...@asert.com.au> wrote: > Nice - though I still wonder whether wrapping within ClosureExpression was > the way to go. > > On the one hand, it makes it clear what return means if you added it in > such a statement (provided you know it is wrapped that way). On the other, > it means that normal if/then/else supports non-local returns but > if/then/else within a declaration doesn't. This is possibly going to be a > little confusing. > > I'd be keen to know what others think. I'm keen to keep the feature but > wonder whether a slight implementation tweak is the way to go. In either > case, we need to document it well. > > Cheers, Paul. > > > On Thu, Oct 5, 2017 at 3:51 PM, Bahman Movaqar <bah...@bahmanm.com> wrote: > >> Beautiful! >> >> >> On 5 Oct 2017 7:18 a.m., "Daniel Sun" <realblue...@hotmail.com> wrote: >> >> The new feature has been implemented, it will be available in 3.0.0 and >> 2.6.0: >> >> https://github.com/apache/groovy/commit/35ae8e484020f2d11b2d >> d9c7efa3740ee527fa70 >> >> >> Cheers, >> Daniel.Sun >> >> >> >> >> -- >> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >> >> >> >
