Implicit versus explicit return

[Alan Karp]

Many moons ago MarkM and I got into a discussion on this topic. I argued strenuously that implicit return was a bad idea. I felt that it was just too easy to add a line and return something you didn’t mean to.

I’m now learning Rust, which has implicit return but with a twist. If your last line ends in a semicolon, the function returns unit, essentially the empty object. If it doesn’t, it returns the result of the expression. I now have all of 10 days experience with Rust and find that I like this convention. I wouldn’t have thought the presence or absence of a semicolon would be enough of a visible cue, but it seems to be, at least for me.

________
Alan Karp

[Dan Connolly]

There's redundancy in the return type. Static type checking changes the balance of risk quite a bit, yes?

--
Dan Connolly
http://www.madmode.com

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+unsubscribe@googlegroups.com.
To post to this group, send email to fr...@googlegroups.com.
Visit this group at https://groups.google.com/group/friam.
For more options, visit https://groups.google.com/d/optout.

[Jonathan S. Shapiro]

On Mon, Dec 19, 2016 at 4:57 PM, Dan Connolly <dc...@madmode.com> wrote:

There's redundancy in the return type. Static type checking changes the balance of risk quite a bit, yes?

In the presence of full (global) type inference, not necessarily.

There's an interesting aside here. The academic PL community went through a long phase of favoring sound and complete inference, and this led to a strong research bias because incomplete type inference work couldn't be published. More recently, incomplete type inference has become palatable again by virtue of being re-labeled "local type inference". The recognition that complete inference for things like polymorphic recursion wasn't feasible went a fair ways toward putting that particular cat back in the [trash] bag.

The benefit of global type inference is that it moves the usability of static languages towards the ease of scripting languages. One cost is that the resulting types only serve as a sanity check if people actually *read* them, and for the most part nobody bothers until they belatedly discover that some procedure call fails to type check in an unexpected way.

Rust's behavior is more than a little odd, to my way of thinking. The ease of unchecked error arising from an inadvertently deleted semicolon when return types are inferred seems problematic, but that may be my own biases showing.

Jonathan 

[William ML Leslie]

On 28 December 2016 at 20:20, Jonathan S. Shapiro
<jonathan....@gmail.com> wrote:
> Jonathan

OT: So glad to have you back Shap! I hope the months have been kind to you.

--
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law. You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

[Dan Connolly]

On Dec 28, 2016 3:20 AM, "Jonathan S. Shapiro" <jonathan....@gmail.com> wrote:

Rust's behavior is more than a little odd, to my way of thinking. The ease of unchecked error arising from an inadvertently deleted semicolon when return types are inferred seems problematic, but that may be my own biases showing.

In Rust, return types are not inferred, with the exception of unit. The documentation could be more clear on this, though.

https://doc.rust-lang.org/1.10.0/book/functions.html

Maybe you could show me an example of the sort of problem you have in mind?