Function statement name syntax in Lua

[Jure Bagić]

Is there any reason this syntax for the function statement name is not valid in
Lua:
> global mymodule = {};
> local name = "OK";
> function mymodule[name] (a, b, ...t)
> ...
> end

In the above, the statement name of the function is invalid as mymodule table
can only be indexed with '.' ('funcname' in the parser) and end with ':'. The
only thing I can think of is that the '.' syntax looks better (more readable)
and the potential errors in '[]' might be hard to debug (expressions => calls =>
metamethods, etc...). However, still not convinced why such decision ("crying
baby noise").

PS
I know I can do:
> mymodule[name] = function(a, b, ...t) ... end

-- Jure

[blogdron (BLOGDRON)]

Just my thoughts out loud :)

 Your first example is almost identical to the second, the only differences being which side the keyword is on and whether there's an equals sign. So, conceptually, they're the same and offer no significant advantages over each other. This means that some people will prefer to write with variant 1, while others will prefer to write with variant 2.

 However, additional syntax checks will slow down the parsing process for EVERYONE, including those who won't use the new feature. In other words, a feature must be valuable, such that its benefits significantly outweigh the downsides. Every feature has a price, and that price is primarily paid by those who don't use it. It's good when a feature can be used in multiple scenarios as a composite construct; it's bad when a feature simply duplicates what already exists, doing nothing but slowing down the language.

It certainly looks funny, but is it worth it? And I'm sure something similar (like hundreds of other syntactic ideas) has already been proposed =) But if we accept them all, we'll get another syntactic mega-monster :)))

четверг, 29 января 2026 г. в 16:16:26 UTC+3, Jure Bagić:

[mjmouse9999]

On Thursday, January 29, 2026 at 11:16:26PM UTC+10 Jure Bagić wrote:
> Is there any reason this syntax for the function statement name is not valid in
> Lua:
> > global mymodule = {};
> > local name = "OK";
> > function mymodule[name] (a, b, ...t)
> > ...
> > end
>
> In the above, the statement name of the function is invalid as mymodule table
> can only be indexed with '.' ('funcname' in the parser) and end with ':'. The
> only thing I can think of is that the '.' syntax looks better (more readable)
> and the potential errors in '[]' might be hard to debug (expressions => calls =>
> metamethods, etc...). However, still not convinced why such decision ("crying
> baby noise").

> [...]

For the final function one reason could be because you have no equivalent way to
call it with a self parameter.

So we have the following for functions as sugar:

function module.this.that(a, b, c) end
-- equivalent to
module.this.that = function(a, b, c) end

function module.this:that(a, b, c) end
-- equivalent to
module.this.that = function(self, a, b, c) end

Is your question also that '.this' above can't be replaced with '[this]'?
(and the final function name is still .that or :that)

    ~$ lua -e 'function module[this].that(a, b, c) end'
    lua: (command line):1: '(' expected near '['

[Jure Bagić]

Can't we have:
> function module.["this"]:[that](a, b, c) end
which would be equivalent to:
> module["this"][that] = function(self, a, b, c) end

My general question is, why the index syntax in function statement names is not
allowed?

-- Jure

[Martin Eden]

On 2026-01-30 06:17, Jure Bagić wrote:
> My general question is, why the index syntax in function statement names is not
> allowed?
>
> -- Jure

Hello Jure,

For me it's questionable favor to programmers from languages where
"function" is name-assigning statement.

In static languages you can't actually run code. You can't

  MyModule = {}
  MyModule[GetFancyName()] = function() end

when your writing package function.

In Lua it's expression, you can create and run function without name.

But you want name if you want reference it to call again.


(From my point of view..)
That function-statement curtsy syntax is not elegant. It emphasizes on
where function is located and hides fact that it is just rigged expression.

  local t = {}

  function t.a() end
  -- vs
  t.a = function() end

And ":" in statement-function definition is just wrong (for me):

  local t = {}

  function t:a() return self end -- What are those "s" "e" "l" "f" ?
  print(t:a()) --
  print(t)  -- Ah, it's parent table! Nice hardcoded name!
  -- vs
  t.a = function(Id) return Id end -- Freudism, but no questions
  print(t:a())
  print(t)

-- Martin

[bil til]

> function t:a() return self end -- What are those "s" "e" "l" "f" ?

... maybe this needs an "additional learning step" for new Lua programmers.

But I think especially for meta-tabels (typically e. g. some C
programmed userdata) this is super-nice and very intuitive.

(e. g. file f..., f:write(...) instead of file.write( f, ...) ).

[Francisco Olarte]

On Sat, 31 Jan 2026 at 12:06, bil til <bilt...@gmail.com> wrote:

....

But I think especially for meta-tabels (typically e. g. some C
programmed userdata) this is super-nice and very intuitive.

(e. g. file f..., f:write(...) instead of file.write( f, ...) ).

Maybe not that intuitive. f.write(f,...). ( It makes a difference, I use it a lot in some modules I wrote, to avoid needing a derived class per object )

Francisco Olarte.

[Martin Eden]

Hello Bil,

I'm talking that ":" sugar in function definition considered harmful.
In function _definition_. Not in function call.

Let me create more ugly example:

  self = {}
  function self:self() return self end
  print(self:self())

What "self" is returned here and _why_?

Versus

  self = { self = function(self) return self end }
  print(self:self())

Good language requires little knowledge to understand.

-- Martin

[Sainan]

> considered harmful

Why does Lua have goto? Don't they know goto is considered harmful?

-- Sainan

[Scott Morgan]

On 01/02/2026 14:13, 'Martin Eden' via lua-l wrote:
> I'm talking that ":" sugar in function definition considered harmful.
> In function _definition_. Not in function call.

TBH, I think that's one place the manual could do with a bit of work.
The `:` function definitions are very common in Lua, but very opaque to
new users. And all you've got is a small, very easy to miss paragraph
buried in the overall description of function definitions.

Possibly needs a clear sub-heading to that section to highlight it as
important. Same for the `:` function call definition.

Scott

[Roberto Ierusalimschy]

> Let me create more ugly example:
>
>   self = {}
>   function self:self() return self end
>   print(self:self())
>
> What "self" is returned here and _why_?

Once you expand all sugar, that statment becomes this:

self["self"] = function (self) return self end

It is not that complicated, but too much sugar is bad for our health.

-- Roberto

[Gé Weijers]

On Mon, Feb 2, 2026 at 10:59 AM Roberto Ierusalimschy <rob...@inf.puc-rio.br> wrote:

It is not that complicated, but too much sugar is bad for our health.

«Syntactic sugar causes cancer of the semicolon.»

Alan J. Perlis

--

Gé