It's not intuitive that these two blobs of code have different token costs, even though they do exactly the same thing:

local a = 1    --  3 tokens: a, =, 1

local b        --  1 token:  b
b = 1          -- +3 tokens  b, =, 1 -> total 4 tokens

I think the disconnect here is that the b in local b is being treated in the cost analysis as a variable reference, which it isn't, because the variable isn't referenced or assigned. It's just forward-declaring a conceptual attribute of the variable (its name), like the zero-cost local keyword does (its scope).

The reason why this bothers me is that I often find myself doing stupid stuff so I can do tuple assignments to save a token, which makes my code ugly. Gross stuff like re-using existing vars or function args, rather than declaring a new local, so I can put them all on the same tuple-assigning line without having to split out a new token-stealing "local" declaration that wouldn't work inline with the tuple assignment.

Here's a really-contrived example you'd never actually write, but hey, I need an example:

function if_period_at_start_move_to_end( s )
  assert(#s >= 2)

  local p                 -- this forward declaration is necessary
  p, s = s[1], sub(s, 2)  -- because we can't mix declare-assign with re-assign here

  if p == "." then
    -- put it where it should be
    s = s..p
  else
    -- phew it wasn't a period, put it back
    s = p..s
  end
  return s
end

Granted I could simply use two new vars when I take the potential period off of the front of the string, thereby allowing myself to merge the local declaration into the tuple assignment, but I guess that just feels like stack clutter to me. I know, nit-picky, but still... it's the little things.

Anyway, unless there's some reason why it would be bad to nix the cost of an empty declaration, would this be an acceptable tweak? I did try to think of some harm or abuse that could come of being able to forward-declare a bazillion locals for free, but the only problem I could see would be in the head of the author who did it.

And, like... at heart, the argument is just that local a = 1 and local a; a = 1 are functionally identical, which I'd hope would be enough in the first place. The rest of the above is just me trying even harder to make a case which I think is already made.

@zep

Since this isn't in 0.2.5e, I'm gonna guess this either didn't get seen or you don't like the idea. Could I get a confirm on not liking the idea? I won't argue, I just want to know if I should forget about this proposal.