[Feature Request] Rename methods to make them more consistent/accessible (e.g. random_si64, atol, isdigit, ...)

[Julian-J-S]

Review Mojo's priorities

• I have read the roadmap and priorities and I believe this request falls within the priorities.

What is your request?

Very exited for mojo and playing around with it from time to time. Noticed some potential improvements regarding method consistency/discoverability. Since feedback on a former issue #3158 was quite positive, I thought I will provide some more feedback.

Type Naming Consistencies

• random_si64 -> random_int64
• random_ui64 -> random_uint64

There is no other place in mojo where "si64/ui64" is used. Everything uses the real type (int64). Method documentation even says that. "si/ui" is inconsistent and new programmers might get confused because they don't know it (we are not all seasoned C/C++ developers).

More Discoverable / Intuitive Naming

• atol -> to_int64 / cast_int64 / parse_int64 (?)
• atof -> to_float64 / cast_float64 / parse_float64 ( (?)

Why use those "cryptic" (ascii to long/float) naming? This is again not consistent, intuitive or discoverable for python programmers or new programmers.

Conform and stick to Standards

• isdigit -> is_digit
• iupper -> is_upper
• ...
  there is already is_power_of_two. So stay consistent. Even when python itself is not.

What is your motivation for this change?

Good, concise naming in a programming language can really benefit all developers in terms of efficiency/productivity and overall experience and should not be underestimated.

Having consistent, intuitive and standardized naming is a great feature!

Any other details?

No response

[Ryul0rd]

atol and atof should probably just be replaced by Int(my_string), Float64(my_string), and similar initializers for other various int and float types since that's what was done for SIMD casting.

[lattner]

+1

[Julian-J-S]

atol and atof should probably just be replaced by Int(my_string), Float64(my_string), and similar initializers for other various int and float types since that's what was done for SIMD casting.

Many developers (myself included) much prefer "chaining" (visual correct order) over "nesting" (reversed order).
Not sure here what the best "mojo" way of achieving this is (probably some conditional conformance / compiler magic; rust from/into style?)

So instead of

C(B(A(x)))

use:

x
.to_a()
.to_b()
.to_c()

Or in the type conversion case instead of

Int(x.do_stuff())

use:

x.do_stuff().to_int()
or
x.do_stuff().parse[Int64]()