Decide and document a guideline for choosing implementation details

[MiSawa]

There are two very different way of choosing how to port the original C++ library;

• Convert the original program into a Rust-friendly way, and
• Try to keep the implementation as same as possible.

For example, there are a lot of ints used as indexing vectors in the original C++ implementation. If it had been implemented in Rust from the beginning, it would have been usize. Another example would be method name, like fn empty() -> bool. While it is very common in C++ to name such a method empty, all such methods in Rust that I know of are named is_empty.

Having a guideline would help make this kind of implementation choosing consistent across modules as well as code reviewers.

[TonalidadeHidrica]

Another point: #3 (comment)

[statiolake]

In my opinion, we should modify the API if it makes codes more Rust-friendly, because:

• our main reason to use Rust in competitive programming is its sophisticated standard libraries and its ability to write bug-free, easily-debuggable codes
• AtCoder has currently no plan to include this library into the judge server environment, so, to speak of extremes, we don't have to have AtCoder Library in Rust (having the same functionality is enough)

However we need a working version of the library. The earlier, the better. Porting would be delayed if we were too sticky to make it Rust-friendly.

So my opinion:

• Convert if it's easy for you to convert, e.g. int -> usize, empty() -> is_empty(), renaming variables and functions to meaningful names, etc. You can change interface if you think it's better, e.g. using ranges instead of start, end pair.
• If it's difficult to decide where to go, changes take too much time, or reviewers and implementors have different opinions and can't agree with each other, then keep original implementation for the time being. It's better to continue development until once it gets completed. Let's fix it later.