Default to LUA_NOCVTN2S and LUA_NOCVTS2N

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Default to LUA_NOCVTN2S and LUA_NOCVTS2N

Fangrui Song
I am a drop-by visitor and just noticed the announcement of Lua 5.4.0 (beta).
(I wanted to reply to "[ANN] Lua 5.4.0 (beta)" but I am not subscribed,
thus I do not know its Message-ID so that I can reply by setting the proper In-Reply-To.)

Is there a plan to make LUA_NOCVTN2S and LUA_NOCVTS2N the default, i.e.
no implicit conversion between numbers/strings?

By making them the default, I envision there might be a need to rename
LUA_NOCVTN2S and LUA_NOCVTS2N to their opposite forms LUA_CVTN2S and
LUA_CVTS2N, respectively.

Reply | Threaded
Open this post in threaded view
|

Re: Default to LUA_NOCVTN2S and LUA_NOCVTS2N

Fangrui Song
On 2019-10-06, Fangrui Song wrote:

>I am a drop-by visitor and just noticed the announcement of Lua 5.4.0 (beta).
>(I wanted to reply to "[ANN] Lua 5.4.0 (beta)" but I am not subscribed,
>thus I do not know its Message-ID so that I can reply by setting the proper In-Reply-To.)
>
>Is there a plan to make LUA_NOCVTN2S and LUA_NOCVTS2N the default, i.e.
>no implicit conversion between numbers/strings?
>
>By making them the default, I envision there might be a need to rename
>LUA_NOCVTN2S and LUA_NOCVTS2N to their opposite forms LUA_CVTN2S and
>LUA_CVTS2N, respectively.

> 8.1 – Incompatibilities in the Language
>
> * The coercion of strings to numbers in arithmetic and bitwise operations
>   has been removed from the core language. The string library does a
>   similar job for arithmetic (but not for bitwise) operations using the
>   string metamethods. However, unlike in previous versions, the new
>   implementation preserves the implicit type of the numeral in the string.
>   For instance, the result of "1" + "2" now is an integer, not a float.

There may be a need to turn off implicit string to number conversion for
this case as well. The behavior corresponds to lstrlib.c stringmetamethods.

  > getmetatable''.__add
  function: 0x55da4540e5dd
  > '3'+'a'
  stdin:1: attempt to add a 'string' with a 'string' # expected
  > '3'+'4'
  7  # unexpected

Reply | Threaded
Open this post in threaded view
|

Re: Default to LUA_NOCVTN2S and LUA_NOCVTS2N

Roberto Ierusalimschy
In reply to this post by Fangrui Song
> Is there a plan to make LUA_NOCVTN2S and LUA_NOCVTS2N the default, i.e.
> no implicit conversion between numbers/strings?

No (at least for now).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Default to LUA_NOCVTN2S and LUA_NOCVTS2N

Fangrui Song
On 2019-10-07, Roberto Ierusalimschy wrote:
>> Is there a plan to make LUA_NOCVTN2S and LUA_NOCVTS2N the default, i.e.
>> no implicit conversion between numbers/strings?
>
>No (at least for now).

That is fine.

There may still be a need to conditionally compile stringmetamethods
with LUA_NOCVTN2S or another macro. See my previous reply.

The incompatibility is introduced in 5.4 . If this is conditioned in
this release, users who define LUA_NOCVTN2S will not see another
incompatibility in this regard when LUA_NOCVTN2S ever becomes the
default.

> > 8.1 – Incompatibilities in the Language
> >
> > * The coercion of strings to numbers in arithmetic and bitwise operations
> >   has been removed from the core language. The string library does a
> >   similar job for arithmetic (but not for bitwise) operations using the
> >   string metamethods. However, unlike in previous versions, the new
> >   implementation preserves the implicit type of the numeral in the string.
> >   For instance, the result of "1" + "2" now is an integer, not a float.
>
> There may be a need to turn off implicit string to number conversion for
> this case as well. The behavior corresponds to lstrlib.c stringmetamethods.
>
>   > getmetatable''.__add
>   function: 0x55da4540e5dd
>   > '3'+'a'
>   stdin:1: attempt to add a 'string' with a 'string' # expected
>   > '3'+'4'
>   7  # unexpected