Re: Subtype [From: [5.3] Converting a floating point number to integer.]

[Tim Hill <drtimhill@...>]

> 
> The above scenario is so common in Lua that it becomes transparent. What I mean is that, I avoid it, work around it, do things in other ways, don't check types, infer types by looking for values, make my own 'subtype` system or... whatever. So, it's not a real problem. 
> 
> BUT, if there was a more formalized, elegant and Lua-esque way to do this, that was at the language level instead of the "loose convention" level (you may choose to take issue with 'loose'), I don't know that things would not be improved. 
> 
> In the case of numbers/integers/integrals/floats, it hasn't mattered to me, very often. It may later. It may matter to a significant number of other people. I don't wish any of the above to be interpreted as an argument for change. 
> 
> All features have costs.
> 
> -Andrew

Extending type to accomodate sub-types has been discussed here before, and rejected for (if i recall) two reasons:

(1) Adding an additional return value to type() for the sub-type would break code like foo(type(...)), which would cause foo() to start getting extra arguments (bad if foo() expects one or more optional args after the first).

(2) A full type system would imply stuff like interfaces, inheritance and who knows what else.

I think (1) is a valid concern, but (2) is very dubious, since it is basically saying we shouldn’t have a better type system unless we can have a perfect one .. good luck with that!

I’ve always liked the idea of an __type() metamethod in the same way we have __tostring(), but apparently that’s also a bad idea (we go ahead and do that anyway in our systems, replacing type() with a custom version that respects metamethods but restricts type() to one return value to avoid (1)).

—Tim