The modification I've occasionally considered would be: - short-form functions implicitly return their expression value; - long-form functions implicitly return `nothing` unless an explicit value is returned.
This could be implemented by automatically inserting a `return nothing` at the end of every long-form function body. I agree that it doesn't help cases where an expression like `a[:] = 1` evaluates to something unexpected. What it does mitigate is accidentally returning some value that you didn't really mean to return. That's not a huge issue since people are free to call the function and ignore the return value, but there is a hazard of people relying on accidental return values which could then change in the future since they were unintentional in the first place. On Tue, May 24, 2016 at 1:19 PM, Jeff Bezanson <jeff.bezan...@gmail.com> wrote: > We did it this way because it's useful in general for the value of a > block to be the value of its last expression (as in lisp `progn` and > scheme `begin`). For example, a macro might want to return some > statements that need to execute before finally computing its value. > The "implicit return" behavior falls out of this. We could maybe add a > check that says "you must write an explicit return", but I find this > to be kind of an arbitrary restriction. It also doesn't fit so well > with other features of the syntax. For example is > > f(x) = 2 > > allowed, or do you have to write > > f(x) = return 2 > > ? > > True, some constructs have non-obvious return values. For example in > > function set1(a) > a[:] = 1 > end > > some might assume it returns `1`, and others might prefer it to return > `a`. If we gave a "must write a return" error, many would just > reflexively add > > function set1(a) > return a[:] = 1 > end > > which doesn't clarify anything. It seems like a documentation problem > to me. If the meaning of a function's return value isn't clear, > requiring people to add redundant keywords doesn't seem like a real > fix to me. > > > On Tue, May 24, 2016 at 12:48 PM, David Parks <davidpark...@gmail.com> > wrote: > > The last line of a function is its implicit return value in Julia. > > > > Can someone tell me why this is a great idea? > > > > I'm realizing a serious downside to it in reading someone else's code. > It's > > not immediately clear to me if a use of a particular function is using > the > > last statement as a return value or not. > > > > The lack of an explicit return is making the code ambiguous to read, and > > therefore I'm searching for uses of it to understand the original intent. > > > > Even if the original coder is being perfectly hygienic in their style, I > > can't make an assumption as such. I've always though explicit over > implicit > > reigned king in code maintainability. Can someone convince me otherwise? > > > > > > >
