Are `_Nullable` really expected in these places?

[everlof]

This is the code produced by KmmResult for me. Isn't it odd that these cases have _Nullable?

- (T _Nullable)getOrThrow __attribute__((swift_name("getOrThrow()")));

- (KmmResult<T> *)onSuccessBlock:(id _Nullable (^)(T _Nullable))block __attribute__((swift_name("onSuccess(block:)")));

__attribute__((objc_subclassing_restricted))
@interface KmmResult<__covariant T> : Base
@property (class, readonly, getter=companion) KmmResultCompanion *companion __attribute__((swift_name("companion")));
@property (readonly) BOOL isFailure __attribute__((swift_name("isFailure")));
@property (readonly) BOOL isSuccess __attribute__((swift_name("isSuccess")));
- (instancetype)initWithValue:(T _Nullable)value __attribute__((swift_name("init(value:)"))) __attribute__((objc_designated_initializer));
- (instancetype)initWithFailure:(AppBridgeKotlinThrowable *)failure __attribute__((swift_name("init(failure:)"))) __attribute__((objc_designated_initializer));
- (BOOL)isEqual:(id _Nullable)other __attribute__((swift_name("isEqual(_:)")));
- (AppBridgeKotlinThrowable * _Nullable)exceptionOrNull __attribute__((swift_name("exceptionOrNull()")));
- (id _Nullable)foldOnSuccess:(id _Nullable (^)(T _Nullable))onSuccess onFailure:(id _Nullable (^)(AppBridgeKotlinThrowable *))onFailure __attribute__((swift_name("fold(onSuccess:onFailure:)")));
- (T _Nullable)getOrElseOnFailure:(T _Nullable (^)(AppBridgeKotlinThrowable *))onFailure __attribute__((swift_name("getOrElse(onFailure:)")));
- (T _Nullable)getOrNull __attribute__((swift_name("getOrNull()")));
- (T _Nullable)getOrThrow __attribute__((swift_name("getOrThrow()")));
- (NSUInteger)hash __attribute__((swift_name("hash()")));
- (KmmResult<id> *)mapBlock:(id _Nullable (^)(T _Nullable))block __attribute__((swift_name("map(block:)")));
- (KmmResult<id> *)mapCatchingBlock:(id _Nullable (^)(T _Nullable))block __attribute__((swift_name("mapCatching(block:)")));
- (KmmResult<T> *)mapFailureBlock:(AppBridgeKotlinThrowable *(^)(AppBridgeKotlinThrowable *))block __attribute__((swift_name("mapFailure(block:)")));
- (KmmResult<T> *)onFailureBlock:(id _Nullable (^)(AppBridgeKotlinThrowable *))block __attribute__((swift_name("onFailure(block:)")));
- (KmmResult<T> *)onSuccessBlock:(id _Nullable (^)(T _Nullable))block __attribute__((swift_name("onSuccess(block:)")));
- (NSString *)description __attribute__((swift_name("description()")));
- (KmmResult<id> *)transformBlock:(KmmResult<id> *(^)(T _Nullable))block __attribute__((swift_name("transform(block:)")));
- (id _Nullable)unwrap __attribute__((swift_name("unwrap()")));
@end

[JesusMcCloud]

Please correct me if I misinterpret the generated code, but this should essentially translate to KmmResul<Foo?> and hence KmmResult.success(null) being legal.

This is indeed intentional so you can use KmmResult with nullables.

[everlof]

Please correct me if I misinterpret the generated code, but this should essentially translate to KmmResul<Foo?> and hence KmmResult.success(null) being legal.

This is indeed intentional so you can use KmmResult with nullables.

Yeah, this is not the case. This is the generated code for KmmResult<T>, where indeed, T could be String?.

Let me you an example from my code using screenshots from Xcode:

So in this case the type is KmmResult<NSString>, however calling getOrThrow returns an optional and is not marked as throwing either:

[JesusMcCloud]

Good catch, thank you! Also: perfect timing, as we're in the process of re-evaluating some design decisions (see #17)
something's not as it should be. This, obviously needs to throw!
We should use this opportunity to also re-evaluate how to transfer catching to ObjC/Swift, while we're at it.

Can I ping you here, once we have a snapshot published, so we have not only our internal tests to verify everything behaves as expected before we push out a release?

[everlof]

Good catch, thank you! Also: perfect timing, as we're in the process of re-evaluating some design decisions (see #17) something's not as it should be. This, obviously needs to throw! We should use this opportunity to also re-evaluate how to transfer catching to ObjC/Swift, while we're at it.

Can I ping you here, once we have a snapshot published, so we have not only our internal tests to verify everything behaves as expected before we push out a release?

Glad to hear! Surely, go ahead and ping!

[JesusMcCloud]

I have not forgotten about this but it will take some more time