In C++ I had quite a few nasty bugs where it turned out that I forgot the return statement, and the function then just returns garbage (if declared as non-void, so I think this can't happen in Julia since you don't declare the return type). At least what is returned in Julia is now clearly defined. I don't think the possible benefits (for some) of returning nothing by default warrant a breaking change like this. On the other hand, I am in favor of putting an explicit return statement in long-form functions as a style guide.
On Thursday, May 26, 2016 at 12:17:29 AM UTC+2, Tobias Knopp wrote: > > No return statement is kind of an explicit indication that the function > does not return anything. This is at least how we know it from a lot of > other languages. Thus at least for me as a previous C++ programmer it > seemed pretty natural. > > > Am Mittwoch, 25. Mai 2016 23:50:50 UTC+2 schrieb Jeff Bezanson: >> >> If we want to change this, I also like the simplicity of Stefan's >> proposal. However, on the whole I agree with Didier and prefer keeping >> things as they are. Automatically adding `return nothing` can be seen >> as making `nothing` the "default return value", which implies that >> returning nothing is a good thing. I also don't feel it answers the >> "explicit is better than implicit" objection that started this thread, >> since the value being returned would not be evident in the code. >> >> On Wed, May 25, 2016 at 3:09 PM, 'Tobias Knopp' via julia-users >> <julia...@googlegroups.com> wrote: >> > I like Stefans idea. Would be great to open an issue for that on >> github. >> > >> > Tobi >> > >> > >> > Am Mittwoch, 25. Mai 2016 15:23:22 UTC+2 schrieb Michael Borregaard: >> >> >> >> To me, the suggested change seems to conflict intuitively with julia >> >> syntax. When using Julia at the REPL all expressions return a value, >> which >> >> is confusing at first when coming from othe languages but quickly >> becomes a >> >> feature. That a function also returns the value of the last statement >> seems >> >> consistent with this. >> >> Also, a common use of multiple dispatch is to have methods that modify >> >> arguments then call another method of the same name defining the basic >> >> functionality. Eg. >> >> >> >> function foo(x::SomeType) >> >> ... >> >> end >> >> >> >> function foo(x::SomeOtherType) >> >> y = dostufftogetsometype(x) >> >> foo(y) >> >> end >> >> >> >> where this syntax seems intuitive. >> >
