Re: Are automatic coercions ever going away?

[Coda Highland <chighland@...>]

On Mon, Jul 28, 2014 at 10:35 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> Is there any plan to remove these from the language at some point? It would
>> allow the authors to simplify the language, as well as remove the
>> possibility yet another type of user error. I understand the removal
>> process involves deprecation as a first-step, but I also understand that
>> Lua is not afraid to break a little backwards-compatibility now and then
>> for the sake of simplifying the language.
>
> In the end, it seems that this "little backwards-compatibility" is far
> from little; these coersions happen in several unexpected places.
> (For instance, the pattern "%d+" does not capture numbers, but numerals.
> Similarly, os.date("%j") does not return a number with the day of
> the year, but a numeral.) So, for now, the plans to deprecate some
> coercions are suspended.
>
> -- Roberto

"%d+" doesn't capture numbers because pattern matching is explicitly a
string operation. There are two possible ways to address this, and in
my opinion both are clean -- either coerce from number to string, or
error when given anything but a string. It's already been agreed that
number-to-string is less onerous than string-to-number, so the former
is acceptable; even more so, if pattern matching is explicitly
documented as using tostring() then it's even well-defined for tables
and userdata with the appropriate metamethods. And since this is
acceptable, there shouldn't be any compatibility breakage.

As for os.date... I do see where you're coming from. Obviously,
os.date explicitly returns a string. User code that assumes that
implicit string-to-number coercion works would break, yes. But
deprecating it for a release (say, for the 5.3.x period) with suitable
tooling (optional warnings?) would give plenty of time for migration.

/s/ Adam