Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Rafael Fourquet]

And indeed, as Scott points, a function can switch from using the
short form to the long form only because the number of characters
grows a bit, which is uncorelated to the functionalness. Having the
short form and long form disagree on the "default" returned value
would increase the risk to introduce a bug each time a conversion to
long form is made.

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Rafael Fourquet]

I would be sorry to see this so elegant functional aspect of Julia
return to the void. It fits well with the
expression-rather-than-statement feel of Julia.
Regarding the annoyance of having to explicitly "return nothing" for
"procedures" (functions which are called only for side-effects): I
would find annoying to having to return explicitly something in
"functional functions", and I like the explicit "return nothing" to
indicate a procedure.
I don't agree that long form functions are inherently non-functional.
First, as Jeff mentioned, the lisp languages (considered functional)
have such features (e.g. "begin" in scheme), to return implicitly the
last expression in a block a mixed imperative/functional code.
This is true also in Haskell in do blocks (which implement side-effect
computations):

greet :: Int -> IO String
greet intensity = do
  name <- getLine
  return $ "Hello " ++ name ++ (take intensity $ repeat '!')

haskell> greet 3
Julia
"Hello Julia!!!"

It should be noted that the return here may be misleading: it's a
standard function which computes a value, which is then *implicitly*
returned to the caller of greet because it's the last expression of
the do block.

Second, a whole bunch a functions are "pure" (non-mutating) and can be
seen as implicit let forms:

function f(x)
y = 2*x
z = x^2
x + y - z
end

which corresponds e.g. in Haskell to

f x = let
  y = 2*x
  z = x*x
in x+y-z

I don't like to argue too much, but the status-quo camp is
under-represented in this thread!

I genuinely don't understand how annotating the function as ::Void or
::Nothing is preferable to "return nothing". And why not a new keyword
"procedure" then?

[julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Ford Ox]

It looks like the problem pple has is the fact that they are not sure what 
their function returns and forget to return nothing. 
If print(methodname) prints automatically it's return type,  you can easily 
avoid this confusion. 

foo()  = 5
>>foo() -> Int

Now you can just easily check what actually your function does. 

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Didier Verna]

Jeffrey Sarnoff  wrote:

> David, if it reads 'complicated' that is my hiccup. The intent was to
> uncomplicate by letting current and future functions do what one would
> expect.

  Which "one"?  DWIM is evil... ;-)
  
-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Didier Verna]

David Anthoff  wrote:

> I like that idea. I think the current behavior is not a huge problem,
> but I often run into a situation where I code up a method that
> modifies something and shouldn’t return anything, and then I forget to
> add a blank return statement at the end (*) and the function returns
> just something arbitrary,

  See it the other way around: in a functional style, there's almost
  always a meaningful value to return. You can simply discard it if
  you're not interested, but if one day you need it, it will already be
  here.


> which can be confusing, especially in interactive sessions a la
> IJulia.

  Then, you're not actually bothered by the fact that a function returns
  a value, but by the fact that an interactive session will print it
  (the P in REPL). This is different.

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Didier Verna]

Stefan Karpinski wrote:

> 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.

  What's returned by a function (in a functional context where
  everything is an expression) is a matter of language semantics. If you
  go down that road, you're introducing semantic discrepancies out of
  syntactic context. Consider that you would no longer be able to talk
  about the concept of "function" itself, separate from the way a
  function object was constructed (in other words, you increase the
  porosity of the syntax/semantic membrane). I think this is a bad idea.

  It's traditional in impure functional languages to return the value of
  the last expression from compound statements; the former ones only
  making sense by side-effecting. Lisp has some constructs to allow you
  to return the value of previous sub-expressions instead, and we
  idiomatically use (values) to explicitly indicate intent to return
  nothing.

  I can see why some people may be bitten by accidentally returned
  values and would like to get 'nothing' by default, but in a
  multi-paradigm language like this one, especially when functional is
  prominent, it's not the language that needs to be fixed. It's the
  people ;-). They're simply not programming in a functional style
  enough and they should learn to do so. It's a long-term gain anyway.

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Chris Rackauckas]

I like Stefan's idea. In fact, this is how I've already been using Julia, 
precisely for scalability. I think that not having an explicit return value 
in a long function is just unreadable, so for long-form functions I always 
add return statements at the bottom. At the same time, there's no reason 
for return statements in f(x,y)=2x*y. Enforcing this convention will likely 
have positive benefits for users in the future.

On Tuesday, May 24, 2016 at 9:16:07 PM UTC-7, David Parks wrote:
>
> I like Stefan's long-form / short-form solution myself. 
> The trivial issue at hand was whether adding a simple print statement at 
> the end of a long-form function was going to break one of the dozens of 
> uses of it.
> That should be trivial, but it wasn't.
> The bigger the project, the bigger this problem. It's an issue of 
> scalability to me.
>
>
>
> On Tuesday, May 24, 2016 at 10:28:33 AM UTC-7, Stefan Karpinski wrote:
>>
>> 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  
>> 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  
>>> 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?
>>> >
>>> >
>>> >
>>>
>>
>>

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[David Parks]

I like Stefan's long-form / short-form solution myself. 
The trivial issue at hand was whether adding a simple print statement at 
the end of a long-form function was going to break one of the dozens of 
uses of it.
That should be trivial, but it wasn't.
The bigger the project, the bigger this problem. It's an issue of 
scalability to me.



On Tuesday, May 24, 2016 at 10:28:33 AM UTC-7, Stefan Karpinski wrote:
>
> 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  > 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 > > 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?
>> >
>> >
>> >
>>
>
>

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Jeffrey Sarnoff]

David, if it reads 'complicated' that is my hiccup.  The intent was to 
uncomplicate by letting current and future functions do what one would 
expect.
The general notion, not entirely captured above, is

function fna{T}(x::T)::T
result = zero(T)
# this and that
result # fna(x) intends that `result` be returned
end

function fnb{T}(x::T)::T
   # this and that
   fna(x)  # fnb(x) intends that the computed value 
`fna(x)` be returned
end


function  fnc{T}(x::T)
result = zero(T)
# this and that
result += fna(x) 
result   # returns result
end

function  fnd{T}(x::T)
result = zero(T)
# this and that
x * fna(x) # returns this
end

function  fne{T}(x::T)
result = zero(T)
# this and that
result = x * fna(x)
show(result)   # return nothing; (autoinserted before end)
end





On Tuesday, May 24, 2016 at 4:03:56 PM UTC-4, David Anthoff wrote:
>
> I think that is a way too complicated rule, no one will know anymore what 
> is happening.
>
>  
>
> *From:* julia...@googlegroups.com  [mailto:
> julia...@googlegroups.com ] *On Behalf Of *Jeffrey Sarnoff
> *Sent:* Tuesday, May 24, 2016 12:58 PM
> *To:* julia-users <julia...@googlegroups.com >
> *Subject:* Re: [julia-users] Lack of an explicit return in Julia, 
> heartache or happiness?
>
>  
>
> Rather than impose `return nothing` on all unshortly functions that do not 
> provide an explicit return, 
>
> perhaps limit postpending `return nothing` to functions that 
>
> neither provide an explicit return anywhere within the function body 
>
> nor have as the final line of the function (before end) either 
>
>   (a) a single variable/value or
>
>   (b) a tuple of variables/values or 
>
>   (c) a conditional/branching that selects either (a) or (b) or throws 
> an exception. 
>
>  
>
> On Tuesday, May 24, 2016 at 2:49:26 PM UTC-4, Tamas Papp wrote:
>
> I wonder if a mandatory return would play well with macros. The neat 
> thing about the Lisp-style syntax is that it is nestable, an expression 
> does not need to care about where it is and whether a return statement 
> makes sense in that context. 
>
> On Tue, May 24 2016, David Anthoff wrote: 
>
> > BUT, if this was to adopted, please do it soon :) These are the kind of 
> > breaking code changes that should get fewer and fewer as 1.0 moves 
> closer. 
> > ​ 
>
>

RE: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[David Anthoff]

I think that is a way too complicated rule, no one will know anymore what is 
happening.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Jeffrey Sarnoff
Sent: Tuesday, May 24, 2016 12:58 PM
To: julia-users <julia-users@googlegroups.com>
Subject: Re: [julia-users] Lack of an explicit return in Julia, heartache or 
happiness?

 

Rather than impose `return nothing` on all unshortly functions that do not 
provide an explicit return, 

perhaps limit postpending `return nothing` to functions that 

neither provide an explicit return anywhere within the function body 

nor have as the final line of the function (before end) either 

  (a) a single variable/value or

  (b) a tuple of variables/values or 

  (c) a conditional/branching that selects either (a) or (b) or throws an 
exception. 

 

On Tuesday, May 24, 2016 at 2:49:26 PM UTC-4, Tamas Papp wrote:

I wonder if a mandatory return would play well with macros. The neat 
thing about the Lisp-style syntax is that it is nestable, an expression 
does not need to care about where it is and whether a return statement 
makes sense in that context. 

On Tue, May 24 2016, David Anthoff wrote: 

> BUT, if this was to adopted, please do it soon :) These are the kind of 
> breaking code changes that should get fewer and fewer as 1.0 moves closer. 
> ​ 

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Jeffrey Sarnoff]

Rather than impose `return nothing` on all unshortly functions that do not 
provide an explicit return, 
perhaps limit postpending `return nothing` to functions that 
neither provide an explicit return anywhere within the function body 
nor have as the final line of the function (before end) either 
  (a) a single variable/value or
  (b) a tuple of variables/values or 
  (c) a conditional/branching that selects either (a) or (b) or throws 
an exception. 

On Tuesday, May 24, 2016 at 2:49:26 PM UTC-4, Tamas Papp wrote:
>
> I wonder if a mandatory return would play well with macros. The neat 
> thing about the Lisp-style syntax is that it is nestable, an expression 
> does not need to care about where it is and whether a return statement 
> makes sense in that context. 
>
> On Tue, May 24 2016, David Anthoff wrote: 
>
> > BUT, if this was to adopted, please do it soon :) These are the kind of 
> > breaking code changes that should get fewer and fewer as 1.0 moves 
> closer. 
> > ​ 
>
>

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Tamas Papp]

I wonder if a mandatory return would play well with macros. The neat
thing about the Lisp-style syntax is that it is nestable, an expression
does not need to care about where it is and whether a return statement
makes sense in that context.

On Tue, May 24 2016, David Anthoff wrote:

> BUT, if this was to adopted, please do it soon :) These are the kind of
> breaking code changes that should get fewer and fewer as 1.0 moves closer.
> ​

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Tom Breloff]

-1 I would be sad if my code was suddenly peppered with "return"
unnecessarily (IMO) all over the place.  I'm sure David was looking at my
code when he was inspired to post this but I would be:
http://giphy.com/gifs/sad-depressed-disappointed-33iqmp5ATXT5m

I'm ok with social pressure to change... just don't force it on me please.

On Tue, May 24, 2016 at 2:36 PM, David Anthoff  wrote:

> BUT, if this was to adopted, please do it soon :) These are the kind of
> breaking code changes that should get fewer and fewer as 1.0 moves closer.
> ​
>

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[David Anthoff]

BUT, if this was to adopted, please do it soon :) These are the kind of
breaking code changes that should get fewer and fewer as 1.0 moves closer.
​

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Eric Forgy]

On Wednesday, May 25, 2016 at 1:34:56 AM UTC+8, David Anthoff wrote:
>
> I like that idea.
>

Me too +1. Not a big deal though, 

RE: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[David Anthoff]

I like that idea. I think the current behavior is not a huge problem, but I 
often run into a situation where I code up a method that modifies something and 
shouldn’t return anything, and then I forget to add a blank return statement at 
the end (*) and the function returns just something arbitrary, which can be 
confusing, especially in interactive sessions a la IJulia.

 

Cheers,

David

 

(*) ``return`` and ``return nothing`` and ``nothing`` on the last line are all 
equivalent, right? 

 

From: stefan.karpin...@gmail.com [mailto:stefan.karpin...@gmail.com] On Behalf 
Of Stefan Karpinski
Sent: Tuesday, May 24, 2016 10:28 AM
To: Julia Users <julia-users@googlegroups.com>
Subject: Re: [julia-users] Lack of an explicit return in Julia, heartache or 
happiness?

 

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 
<mailto: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 
<mailto: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?
>
>
>

 

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Stefan Karpinski]

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 
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 
> 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?
> >
> >
> >
>

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Jeff Bezanson]

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  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?
>
>
>

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[Isaiah Norton]

This is common in more functionally-oriented languages, and facilitates a
similar style in Julia. I would probably ban it in an organization-level
linting standard, but I do use it myself ;)

On Tue, May 24, 2016 at 12:48 PM, David Parks 
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?
>
>
>
>

[julia-users] Lack of an explicit return in Julia, heartache or happiness?

[David Parks]

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?