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

[Flyer31 Test <flyer31@...>]

Thank you for idea support.

Concerning these 3 new operators ++, **, // I must admit, that this
"somehow a bit awkward" ... and you have to bear in mind that --
already used for line comment, and == already used for comparison.

But as I explained in my last post from this morning, I do NOT expect
MANY people will use these new commands ++, **, //. If you read
through the answers in this thread, you will see that even experienced
Lua users did not even use // so far... .

Just: For SOME people such int arithmetic IS important ... but I am
really very sure that this is NOT more than 1% of lua users. Those 1%
will be CLEAR PROGRAMMING SPECIALISTS, and they clearly will know what
they do, and they clearly know how to hide such "more unusual code" in
some sort of "background functions".

I just also looked a the youtube video proposal of Roberto, thank you
for this. From this I recognized that I of course completely forgot
the important applications of encrypting. Ecrypting coding I think
USUALLY will also mainly use "standard bit manipulation operators"
(mainly bitwise and(&)/or(|)/xor(~)/not(~), and << and >>). So mainly
this encryption applications will be in the field of "bit witchcraft
handling".

SOME times such encrypting of course might use integer arithmetics,
but IF somebody programs encryptings in Lua, I think this person quite
clearly will fall into this ca. 1% "specialist Lua users" who know
very well what they do, and such specialist users from my
understanding should have no problems to clearly distinguish **, //,
++ from standard *, /, +.

... and I think the "normal Lua users" will just somehow ignore these
commands ** // ++ and will not use them any time (which of course is
better for them :) ).



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.
>