lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Am 01.08.2014 13:31 schröbte Thijs Schreijer:

Op 31 jul. 2014 15:55 schreef Dirk Laurie <dirk.laurie@gmail.com>:

2014-07-31 15:24 GMT+02:00 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:

Just in case, Lua 5.3 will have compile-time options for easily
disabling these coercions (one for string->number, another for
number->string), but the "standard" will be with coercions enabled.

This is a model that might be extended to various other aspects
that people have been clamouring for (i.e. at least one person has
diffidently requested). A feature that is not in current Lua, but easy
to do, is controlled by a compile-time option that does not carry
the taint of deprecation. I like it.


I don't like it. The consencus was clear; string -> number coercions are bad and should go. Number -> string was considered a lesser evil. As the compile time options are now in the 5.3 alpha, it starts complicating things.

I can't read minds (only short distance, not across the atlantic) so I can only assume that the options mean, that sometime they will be deprecated and removed. As such, these compile options blur the clear process of deprecation with compat option, and final removal in the next release. By adding some step in front with extra options, the process gets less clear.

The options in itself will mean a further divergence in the Lua landscape, besides versions and compat options one now also needs to check for these options as well. More complications...

So if they are going to be removed anyway, I'd rather see the string -> number coercion be deprecated now and live on under the compat option. I don't mind the number-> string coercion, but if needs be, let that one take the same route.

The comptibility issue will have to be dealt with anyway, if not now, then later. And the issue is fairly simple, as any fix for 5.3 will work backwards on 5.2 and 5.1. In this respect the integer divison operator is a far bigger incompatibility as it will return compile time errors on older versions.

So don't be shy, just drop them.

I agree.

But I also want to mention that I explicitly *added* number->string coercions (using `i..""`) just two days ago to account for fools who add `__tostring` metamethods (which can raise errors) to numbers. So I'd really like to have `rawtostring` in case implicit coercions go ...

On the other hand, I can't remember a case where the implicit string->number coercions caused me any problems -- I successfully avoided them so far.


Thijs


Philipp