Re: Are automatic coercions ever going away?

[Steven Degutis <sbdegutis@...>]

Oh wow. That's actually pretty unsettling. I remember reading in PIL
(third edition) to be careful about this, and even seeing it a second
time is still a bit unsettling.

In fact, I just checked my code to see if I had a similar bug.
Fortunately I used lua_type instead, testing against LUA_TSTRING etc:

https://github.com/sdegutis/hydra/blob/7abe8b93664170451fc93559123839169addc301/Hydra/Bootstrapping/helpers.m#L184-L229

On Fri, Aug 1, 2014 at 2:57 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Coroutines once stated:
>> On Fri, Aug 1, 2014 at 8:19 AM, Roberto Ierusalimschy
>> <roberto@inf.puc-rio.br> wrote:
>>
>> > Just a few days ago we sent a message stating that we are not sure about
>> > this whole thing anymore [1]. You probably missed it.
>>
>>
>> I have trouble taking the whole 'coercion in lua is bad' thing anyway.
>> It's not like Javascript where you can concatenate and add two things
>> together with the same operator (+).  I am never confused about this
>> in Lua as + will derive numbers, and .. will derive strings.  There is
>> no overlap for operator use.  I don't find these "coercion sites" very
>> ambiguous even if metamethods are called from left-to-right on
>> availability.  I'm just tired of people who hate coercion in every
>> language speaking like they know what's best for Lua from an
>> ideological pedestal.  I do agree that have the option to disable or
>> leave enabled coercion might have the potential for a fragmented Lua
>> community, but I find the prospect very unlikely.  The only rift I've
>> ever seen has been between Lua<->LuaJIT.
>>
>> I can't think of any such places but I know there must be code hiding
>> in the C side of Lua where coercion should be possible (following the
>> normal rules) but isn't.  I'd like to see more work done to remove
>> these situations -- otherwise I'm already happy.
>
>   One situation I hit in C was the following:
>
>         static int foobar___index(lua_State *L)
>         {
>           foobar__s *foo = luaL_checkudata(L,1,TYPE_FOO);
>
>           if (lua_isstring(L,2))
>             ...
>           else if (lua_isnumber(L,2))
>             ...
>         }
>
> Odd bugs until I actually read the description for lua_isstring():
>
>         Returns 1 if the value at the given index is a string or a number
>         (which is always convertible to a string), and 0 otherwise.
>
> lua_to[l]string() will do a convertion if the target is a number.  I'm sure
> it's convenient in some cases, but not in others.
>
>   Oddly enough, I dont' have an issue with lua_isboolean() or
> lua_toboolean() even though they do a conversion as well (nil or false as
> false, anything else is true).
>
>   -spc (For now, I just check for numbers first, then strings ... )
>