Re: Are automatic coercions ever going away?

[Dirk Laurie <dirk.laurie@...>]

2014-07-28 19:50 GMT+02:00 Coda Highland <chighland@gmail.com>:
> 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.

It sits rather deeply in the implementation.  Those two examples
are merely "for instance". The string "tonumber" appears on 35
lines of the source code. Thus even though a desirable thing to
do, it is so troublesome that it has not been done yet, whereas
some other things that are less desirable are so easy to do
that they have been done already.