Please mark this as "Ready for review" when ready. If you have any doubt, please ask.

@Shaikh-Ubaid I do have some doubts. They are related to throwing errors.

1. Where should the case of an invalid string literal passed to the numeric types be handled? Before coming to the casting part, we cannot be sure that the passed value is an integer enclosed inside a string. This can be dealt with before we call the cast_helper, but then again, we would be repeating the same code as that in the casting. Handling the same during casting is not clean in my view.
2. This is very important. We will have to handle the case of an integer larger than the storage type passed to the variable. stoi and stol handle that for us for i32 and i64, but for the smaller ones it leads to the overflow.

My chief concern is that while both of these can be done while casting, it is not clean, and probably not supported there too.

Sharing my thoughts on this:

• I think string to integer is more of a conversion rather than a casting operation.
• So for now let's not use i32, i16, ... to cast string to int. Let's reserve them only for casting from other integers and floats to integers
• Now for conversion to string, let's use the int() function

I believe the above approach solves all your concerns.

Also see #2554 (comment).

Now for conversion to string, let's use the int() function

I think there is a catch. @certik said that int() will mean an arbitrary precision integer in future for LPython. Considering the case of a hexadecimal or an octal number, the result of something like i32(int("0x101100", 16))" will cause an error as the value is too large to fit in an i32.

Supporting your idea and building upon it, I think we need to not just cast a string to an integer, but convert it. Please let me know your thoughts on this. :)

But again, we can surely build on top of the support we have for int() now. Let's work out a plan for that.

int() will mean an arbitrary precision integer in future for LPython.

I think the type int would mean an arbitrary precision integer. For example, x: int. I think for now it is safe to use int() for string to int conversion.

Considering the case of a hexadecimal or an octal number, the result of something like i32(int("0x101100", 16))" will cause an error as the value is too large to fit in an i32.

Let's just focus on normal/decimal (base 10) integers for now. Once that is robustly supported, we can try supporting integers of other bases.

But again, we can surely build on top of the support we have for int() now. Let's work out a plan for that.

Sure, go ahead and make a plan. Figure out what is left to be supported for int() or what fails and you can work on fixing it.