capi Dart todos

[robertbastian]

Just collecting some notes:

• ICU4XReorderedIndexMap::as_slice returns a &[usize]. I need to figure out how to port this to Dart
• ICU4XDataStruct::create_decimal_symbols_v1 accepts &[char]. There's no char type in Dart, it allows code point iteration but the items are strings. We could use List<String> or List<int> for this
• Dart is native Utf-16, but in Diplomat we don't know if a given &[u16] is a string or not, so currently I have to put Uint16List on the API
• Some apis return Result<_, ()>. This is fine in C++, but we want something to throw in Dart. Check what JS does.

[robertbastian]

cc @Manishearth

[Manishearth]

For the utf-16 stuff we have a separate issue: rust-diplomat/diplomat#240 and getting a DiplomatWriteable16 . These don't exist right now.

Dart is native Utf-16, but in Diplomat we don't know if a given &[u16] is a string or not, so currently I have to put Uint16List on the API

I'm confused, you'd be converting these at the boundary, yes?

There's no char type in Dart

Not uint32_t type either?

Check what JS does

JS throws.

[robertbastian]

I'm confused, you'd be converting these at the boundary, yes?

I'm confused. The question here is if we can use the String type, because we don't want Uint16List on the API if it's actually a string.

Not uint32_t type either?

No, there's only int, which is platform dependent, 64 bits on the VM, and 54 bits on web.

JS throws.

But what does it throw?

[Manishearth]

I believe JS throws an FFIError type that wraps the internal error type.

I'm confused. The question here is if we can use the String type, because we don't want Uint16List on the API if it's actually a string.

We should use native dart types in the final interface, yes. That's different from what we use under the hood.

[robertbastian]

I believe JS throws an FFIError type that wraps the internal error type.

The linked API throws a () error.

[Manishearth]

I believe those are just FFIErrors with nothing inside them

[robertbastian]

We should use native dart types in the final interface, yes. That's different from what we use under the hood.

The problem is that we cannot tell whether it should be a String, i.e. valid UTF-16, or a Uint16Array, which could be anything, because on the Rust side it's just &[u16].

[Manishearth]

yeah we need to add a UTF16String type to diplomat.

[Manishearth]

For now I would diplomat::skip UTF16 dart things and only handle the more expensive utf8 ones