Re: [PROPOSAL 5.4] alternate way of format/pack/unpack (in the string library)

[Sean Conner <sean@...>]

It was thus said that the Great Frank Kastenholz once stated:
> Hi
> 
> What is the problem that this is meant to solve?
> 
> Embedding formatting instructions in strings is not a problem; modern C
> compilers, for example, evaluate printf() format strings at compile time
> and report on format/argument mismatches.  If it can be done in C it can
> be done in Lua/LuaJIT, no?

  To a degree.  C can check the following:

	printf("%s is %d units high\n",unit->name,unit->height);

because the format string is an immediate value, and because C has types,
the parameters can be checked for typeness as well.  C can't however, do a
check like:

	printf(unit->format,unit->name,unit->height);

because the string is not available at compile time to do the check (but
this is still legal C code).  So there are limits that even C has.

  Now, for Lua:

	string.format("%s is %d units high\n",unit.name,unit.height)

About the only thing that can happen at compile time is to check that the
number of format characters matches the number of parameters given to the
function.  There's no way to check that unit.name is a string, or that
unit.height is a number, because there's no definition of what 'unit' is. 
And it's values that have types, not variables (or fields in a table).

  What I *would* like to see for string.format() is an option (or new
function) that coerces the parameters to the given type instead of throwing
an error.  I can live with the current situation though (annoying as it is).

  -spc