Re: Wishful request for next version: '// 1' should produce integer

[Flyer31 Test <flyer31@...>]

PS: Why do you think that Lua has lost its "simple coding style" since
5.3? Can you give some examples?

(I programmed now really quite severe things in Lua, always thinking
about being in "simple programmer perspective" (as far as I can
imagine this :) ), and I am still 100% convinced of the coding style
of Lua - I did not see any real drawbacks so far... .).

On Sat, Jan 8, 2022 at 6:56 PM Egor Skriptunoff
<egor.skriptunoff@gmail.com> wrote:
>
> On Sat, Jan 8, 2022 at 2:04 PM Flyer31 Test wrote:
>>
>> Supporting "int number arithmetics" in int style has this clear
>> disadvantage / risk of sign inversion in case of overflow.
>> ......
>> - use the standard arithmetic binary operators +, -, * , /, ^
>> EXCLUSIVELY in float number stlye
>> - use COMPLETELY NEW binary operators specifically for int
>
>
> The idea is correct.
> To make programs more understandable and less error-prone,
> the semantics of arithmetic operators should be 100% defined by the operator itself,
> not by the type of operands.
>
> But your suggestion would make integer expressions very hard to read.
> And I don't know a good solution to the problem.
>
> Starting with version 5.3 Lua has lost its simplicity (the most attractive side of Lua).
> Now you are doomed to always be wary of the difference between numeric subtypes.
> Integers in Lua are now forever, there is no way back to almost perfect Lua 5.2.
>
> No doubt integers are sometimes useful in Lua programs.
> But I'd prefer to have them as an FFI extension instead of as part of core Lua.
> Such FFI extension should be able to do:
> 1) everything LuaJIT FFI does and
> 2) be able to compile functions written in platform-native ASM.
>