Regarding your point about function calls, this is actually something I opened an issue about a while back, and it seems the consensus was against it (although I do still think it would make sense, personally).
https://github.com/JuliaLang/julia/issues/7411 On 27 Jul 2014 18:29, "Magnus Lie Hetland" <[email protected]> wrote: > I assume there's a fundamental reason for this, having to do with the > fundamental role of tuples, but … why are assignments not allowed inside > them? > > Not that that's a crucial piece of functionality, but it might be useful > if one wanted to return multiple values, where the later depend on the > former, in a simple function. (I have such a case right now, actually ;-) > > For example: > > *julia> **f(x) = (y=2x, sqrt(y))* > > *ERROR: syntax: assignment not allowed inside tuple* > > The fix is easy enough: > > *julia> **f(x) = {y=2x, sqrt(y)}* > > *f (generic function with 1 method)* > > But the canonical way of returning multiple values is using tuples, no? > (Less overhead as well, perhaps?) > > With multiple statements, it works, of course: > > *julia> **f(x) = (y=2x; (y, sqrt(y)))* > > *f (generic function with 1 method)* > > But then it'd be better to just use a block definition, I guess. > > So … what's up with this interdiction? Mostly just curious :) > > This may be related to another question that also involves assignment > expressions—using them in function application. Not possible either, it > seems? > > *julia> **sqrt((x=2))* > > *ERROR: function sqrt does not accept keyword arguments* > > Why is this interpreted as a keyword argument? Are the parentheses > “optimized” away, so it just looks that way once time comes to > compile/evaluate? Must they be? Would be useful (and consistent) if > assignment expressions could be used in all the places where the RHS could > be used. I realize they couldn't be used without the parentheses in the > previous expression—that syntax already has a clear definition. But the way > it's written here … why not? > > (Given that tuples are sort of a representation of the arguments of a > function, I guess the two are related, at least tenuously?) >
