lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Being the one that opted for the two return values, I must say that I agree with Steve and Roberto that having to create a local for just accessing the second return value is a bad practice. 

Then I would rather have a single type() function and replace its 'number' return value with the new types. Big incompatibility but the new integer division operator already is. Incompatible but clean. 


-------- Original message --------
From: John Hind <>
Subject: Re: Lua 5.3 work1 Considering math.isinteger or type()

Still seems to me that a second return value from type() is by far the most
straight forward solution to this. Anyone who does not like this can easily
front it with a wrapper in Lua to do it however they wish.

This could also be usefully extended by a new '__type' metatable key. If
present, its value would be returned as the second return from type(). So
classes/types created from table or userdata type could easily be set up to
return an appropriate sub-type.

> Date: Mon, 22 Jul 2013 09:04:59 +0200
> From: David Demelier <>
> Subject: Re: Lua 5.3 work1 Considering math.isinteger or type()
> To: Lua mailing list <>
> Message-ID:
>        <CAO+PfDfs6ke3Gpko8n4NTU6imm2-
> Content-Type: text/plain; charset=UTF-8
> 2013/7/19 Philipp Janda <>:
> > Am 19.07.2013 10:00 schrC6bte Pierre Chapuis:
> >
> >>> Well, my suggestion of sticking debug.subtype() inside type() was
> >>> meant to sidestep the issue of where to put it, while keeping the
> >>> API function count low. I'm not strongly advocating it, just
> >>> contributing
> >>
> >>
> >> For what it's worth, I agree with that idea.
> >> I really don't like the idea of putting subtype() in debug.
> >
> >
> > I'm fine with `debug.subtype`, although I probably would call it
> > `debug.type`, just like `debug.setmetatable` provides a superset of
> > functionality compared to plain `setmetatable`.
> >
> > But do we need that function at all? Are there any use cases where
> you
> > want to know the actual subtype of functions or userdata in Lua code,
> > or is this just for the sake of completeness?
> >
> > At the moment, my preferred solution would be math.type (like
> io.type,
> > lpeg.type, etc.):
> > *   no new global variables
> > *   no new names
> > *   no unfamiliar calling conventions
> > *   if people remove debug functions, they probably won't make an
> exception
> > for harmless functions like (sub)type
> > *   the only reason to remove `math` is if you don't have floats in
> which
> > case this function becomes obsolete anyway
> >
> Yes, math.type looks absolutely the best solution!