I don't think we should make ::Void a special case. On May 25, 2016 8:16 PM, "Qian Long" <longqian9...@gmail.com> wrote:
> Why not just let "function foo(...)::Void" return nothing as default and > others just keep as they are. > > On Thursday, May 26, 2016 at 8:35:27 AM UTC+9, Miguel Bazdresch wrote: >> >> I think this is similar to the distinction between 'function' and >> 'procedure' in languages like Pascal. Maybe we could leave functions as >> they are (which I'd prefer), and add procedures that are like functions but >> with an implicit 'return nothing' at the end. >> >> -- mb >> >> On Wed, May 25, 2016 at 6:40 PM, Stefan Karpinski <ste...@karpinski.org> >> wrote: >> >>> An argument for `nothing` being a good default return value is that it's >>> very unlikely to accidentally work. Here's a scenario that illustrates the >>> problem. Suppose you call a function that's supposed to return an integer – >>> maybe the write function, which has many methods and returns the number of >>> bytes written to the I/O stream. But someone implementing a write method >>> (maybe a custom one) forgot to end the method definition with an expression >>> giving the number of bytes written – this is easy to do since the primary >>> purpose of `write` is to output data, not compute how much data is output. >>> However, the function is written so that the last expression happens to >>> evaluate to an integer – but not the number of bytes output. This is also >>> pretty easy to do – IIRC, we had a bug in Base where exactly this happened. >>> The caller gets no hint that there's a problem, they just get a subtle and >>> hard-to-find bug. If, on the other hand, the function just returned >>> `nothing` because there's no explicit return, then they would immediately >>> get an error when they tried to use the return value where an integer is >>> expected. In short, `nothing` is a good default return value precisely >>> *because* it is useless. >>> >>> On Wed, May 25, 2016 at 6:17 PM, 'Tobias Knopp' via julia-users < >>> julia...@googlegroups.com> 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. >>>>> >>>> >>> >>
