Unclear constraints on Indexer types

[tadfisher]

The documentation on indexing states:

[] can be overloaded in languages that support it by applying an indexer attribute to a method that takes an integer argument and returns an Option.

However, Dart doesn't check the indexer type and will happily generate the following (from ICU4X):

  /// See the [Rust documentation for `get`](https://docs.rs/icu/latest/icu/locale/struct.LocaleDirectionality.html#method.get) for more information.
  LocaleDirection operator [](Locale locale) {
    final result = _icu4x_LocaleDirectionality_get_mv1(_ffi, locale._ffi);
    return LocaleDirection.values[result];
  }

While the Kotlin backend does check that the indexer type is an Int and will fail for the same function with:

thread 'main' panicked at /home/tad/.cargo/git/checkouts/diplomat-6c8ebb579fc79396/0183677/tool/src/kotlin/mod.rs:1063:30:
index type must be an integer type

Technically, Kotlin supports overloading the indexing operator with arbitrary types, so the two backend languages that support the indexing operator don't have the indexer type restriction noted in the docs, and only one backend actually checks the indexer type.

So I suppose this is a request to either:

• Implement the documented index type restriction on the Dart backend; or
• Allow arbitrary indexer types on the Kotlin backend, and update the documentation. Future backend support would need to elide operator-overload generation based on their language's restriction on indexer types for these overloads.

[Manishearth]

Backends are allowed to be more or less picky, so what I'd actually say is that we should have a supports = arbitrary_indexing CFG and Kotlin turns it off, until it gets support.

[robertbastian]

I think the documentation is wrong. Indexing was never intended to be integer-only, and afaict all languages that have language-level indexing (Dart, Kotlin, C++) don't restrict it to integer types.