search

haxetink / tink_core

Core utilities
https://haxetink.github.io/tink_core
MIT License
117 stars 33 forks source link

Should `Promise.noise()` just return the promise itself? #130

Closed nadako closed 4 years ago

nadako commented 4 years ago

Given that Noise has from Dynamic so this is possible:

var s:Noise = "not null";

(and thus there's no guarantee that two Noise-typed values are equal)

Shouldn't Promise.noise just return this to save some allocations?

nadako commented 4 years ago

Also I need some clarification about the deprecation of Promise/Future.NULL, e.g. if I have:

var f:Future<String> = if (...) getActualFuture() else Future.NOISE;
f.handle(value -> /* should I check for `null` here? */);

To be honest I'd prefer something that is explicitly specified to resolve to a null, especially given that Noise can be anything because of from Dynamic...

back2dos commented 4 years ago

The code should not compile with null safety, because Future<Noise> is merely Future<Null<String>>.

And yeah, the from Dynamic is new and should probably be given more thought. Probably @:from Dynamic return null would be better.

nadako commented 4 years ago

So does that mean that Noise is/should be specified to be null at run-time? ^^

back2dos commented 4 years ago

Indeed. The whole point was to have only one value. I think :D

nadako commented 4 years ago

Hm, I wonder if it makes sense to have a cached instance of Outcome(Noise) too (for Promise.noise).

back2dos commented 4 years ago

Why not ;)

kevinresol commented 4 years ago

Need this https://github.com/HaxeFoundation/haxe-evolution/issues/10#issuecomment-296135253 ?

back2dos commented 4 years ago

Not necessarily, but it'd be a nice solution :)