Re: Are automatic coercions ever going away?

[Andrew Starks <andrew.starks@...>]

On Friday, August 1, 2014, Thijs Schreijer <thijs@thijsschreijer.nl> wrote:

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.

Thijs

I agree with this. I would rather that a binary of PUC Rio Lua act like any other, accepting allowances for capacity and extreme platform constraints. 

If the intent was to provide people a simple way to test the effects of turning it off, then it's understandable. Hopefully there won't be a libraries popping up that depend on one behavior or the other.

IMHO.