Re: RFC: "in place" return from imperative function calls

[Dennis Fischer <darkwiiplayer@...>]

Okay, criticism:

1. You don't save much typing
2. It's more syntax to learn
3. It's more logic in the parser
4. It hides assignment operations
5. It goes against how Lua is otherwise designed

The fourth point is probably my biggest problem with the proposal.
In Lua, assignment to variables always looks the same: variable(s) to
the left, equal sign, values to the right.
It's easy to visually parse and makes it clear that the value changes.

Adding a new syntax that assigns a value to a variable seems like a bad
idea to me because it means there's
another syntax structure that you need to scan for when looking for
where a variable is changed.
Even worse is the fact that it's a single character, which is very easy
to miss. Missing one & character
could completely change the meaning of a piece of code.

The fifth point may also need some explaining: I don't think it's a very
"Lua" way of writing code.
It looks a lot like C, in a bad way. Lua has always leaned more towards
the functional side when
it comes to syntax, while allowing imperative code more than encouraging it.
I believe this has worked well because it lets newcomers write codes as
simple sequences of
instructions but directing them towards a more robust coding style as
they dig deeper into the language.
This proposal would have the opposite effect; directing them to more
imperative C-style code,
which eventually would lead to more frustration because a) the code
quality would be worse and b)
they'd hit the limits of the language at a later point, because Lua
still wouldn't be a very good language
for expressing complex logic in an imperative way; but from that point
it would be harder to find back
to a better style that fits the languages strengths.

I do see a similarity with the table:method() syntax here, but while
that one basically makes an entire
programming paradigm (OOP) available to Lua, your proposal would really
just be a very situational thing,
so there's not as much reason for adding it. The trade-off is just not
worth it in this case.

I do see your point and don't believe it's a bad idea per se, I just
don't think there's a strong enough case
for adding it to a language that aims to be as small as possible.

On 13/08/2019 06:11, Griffin Rock wrote:
> Proposed ability to 'mark' an argument in an imperative function call to transform it into an assignment statement.
> Can be implemented as a purely syntactic translation with no change to the behaviour of the function or interpreter.
> Syntax below uses unary '&' like c pointers and c++ reference signatures.
>
> examples of use:
> "trim(x, & veryLongName, z)" => "veryLongName = trim(x, veryLongName, z)"
> "string.gsub(& line, '%s+', ' ')" => "line = string.gsub(line, '%s+', ' ')"
>
> probably only useful on locals, since you can already "manually" translate
> "trim(& veryLongName[complexLValue])" => "zap(trim, veryLongName, complexLValue)"
>
> Criticism welcome.