Re: Are automatic coercions ever going away?

[William Ahern <william@...>]

On Fri, Aug 01, 2014 at 06:19:26PM -0400, Sean Conner wrote:
> It was thus said that the Great William Ahern once stated:
<snip>
> > I'm not a C++ programmer, but there's a parallel with the ranking of
> > implicit conversions when dealing with overloaded functions.
> > 
> > Because of Lua's metamethod devices it's important to always be in the habit
> > of generating a loose hierarchy of types in your mind when implementing
> > function overloading. Otherwise they go to waste. If implicit coercions
> > didn't have significant value, neither would metamethods.
> 
>   I don't think that way.  I don't use metatables for tables, I use them for
> userdata, and for all the userdata interfaces I've written, I've found one
> that overrides something other than __call, __index, __newindex, __gc,
> __tostring or __len [7], that's how rarely I do overloading. [8]

If somebody is checking the type of a method argument and does X if the
argument is an integer and Y if the argument is a string, that's
overloading.

Someone actually doing that should be thinking about the rank of argument
types. Especially from the Lua C API because the AST isn't visible to hint
at what the caller intends, unless they're using metamethods like __concat
or __add.

<snip>
> > Yes, often times you're trying to cram a square peg into a round hole. But
> > it's darned convenient. It's up to the programmer to rank things so he tries
> > fitting the round peg into the round hole first. Abstractions have costs
> > because they necessarily obscure context. But that's their value!
> > 
> > I feel like the obsession with stricter typing is turning into an
> > anti-pattern.
> 
>   I've checked the source control logs and over the past month, I've logged
> 50 bugs in a work related project written in Lua [1].  Four of the bugs are
> work arounds to bugs in other components I have no control over; two were
> reverted (found not to be a bug or the wrong fix for a bug); 31 were logic
> or misunderstandings (in other words, a compiler would not have caught
> these) and the remaining 13 were bugs that a compiler or stricter typing
> would have caught. [3]
> 
<snip>
> [3]	Now, one might reasonably ask why 13 typos got into the source
> 	control reposity.  I might answer as that's the only way to get the
> 	code to the target machine for interoperability testing [4].  This
> 	is also the first time I've seen actual SIP messages from the wild
> 	[5].

But were any of those bugs caused by string-number coercion? Or the lack
thereof?

I'm not questioning whether strict typing _generally_ helps to mitigate
bugs. I'm arguing that it's not clear to me that string-number coercions
_specifically_ are hiding real bugs. And the potential risk, if any, should
be weighed against the tremendous convenience.

In C it's generally recommended to cast as little as possible because
casting prevents the compiler from complaining, hiding possible bugs. More
often than not you want the compiler and run-time to handle conversions if
possible because they're not going to make any mistakes, and will apply
sensible, default rules rigorously. And it's okay to rely on that support;
it's not a crutch.

You know a piece of software is bad when you see casts all over the place.
People get into the mode of casting everything everywhere because they can't
be bothered to carefully think about typing issues for every single
expression. But why should they even have to be bothered if the compiler can
handle 90% of the work load using a set of simple rules for implicit
conversions?

Stroustrup said that he made his casting operators intentionally ugly to
discourage casting. C++ has stricter type checking than C, yet IME the
average C++ project contains way more casts than your average C project.
Unintended consequences....