Re: Are automatic coercions ever going away?

[William Ahern <william@...>]

On Fri, Aug 01, 2014 at 03:05:50PM -0500, Steven Degutis wrote:
> I have indeed found times where I wasn't sure every value in a table
> was a string when I needed to run it through table.concat. But other
> times I already knew they were strings, so running tostring() on them
> within table.concat would have just been a waste of CPU.
> 

Just my opinion, but I feel like string coercions are just too convenient.
Most dynamic languages support them, IME, perhaps excepting Python.
JavaScript has rather unintuitive behavior, but that's because it overloads
the + operator with concatenation.

I understand and deeply appreciate the value of stronger typing. But small
conveniences like this pay enormous dividends in terms of productivity and
have very little cost.

Coercions can be thought of as very inuitive generic programming devices.
The value in this can be seen in the evolution of C's integer implicit
conversions. As compiler diagnostics become stricter about implicit
conversions, C programmers must deal with an endless stream of ugly and
useless casts. Heck, Lua relies on twos-complement representation,
unsigned-to-signed conversions, and unchecked narrowing conversions, because
it's just so darned convenient and in reality safe (everytime I think I find
a potential security issue with Lua's implemented-defined coercions I can't
actually find a case that would trigger undesirable behavior). But Lua
need's to pepper its code with explicit casts, which _should_ be
unnecessary.

I personally try very hard to avoid unsigned-to-signed coercions in C, but
the fact of the matter is that new languages purposefully make this safe
because it's just too impractical to do otherwise. It's a waste of a
programmers time to deal with this stuff when the compiler and run-time can
do it using very simple and consistent rules.

The cases where type-safety in this regard really matter are few and far
between. And developers are free to explicitly manage conversions.

I really do value Lua's simplicity. But I think its string and number
coercions add to this quality, rather than detract. The small complexity it
adds to the VM is paid for many times over in productivity in the language.