Feature - Deferreds without parameters

[brendanjerwin]

There are a few cases where it'd be nice to have a Deferred that had no payload type. In that case, .Then would take Void->Void.

The fact that it resolved or failed is all the information that is needed in some cases.

(failing would still carry the error though.)

[jdonaldson]

Sorry for the delay. I'm keeping this in the back of my mind, but I don't have a pressing need for the proper feature since a workaround is so easy.

[brendanjerwin]

While it is true that the workaround is easy, it does clutter up my APIs with misleading information.
"What am I supposed to do with this boolean?" my clients are asking. :)

[jdonaldson]

I'll keep this open, but for what it's worth this seems pretty unlikely that I'll get it working properly.

Firstly, some haxe targets have a problem with a Promise type, as seen in #20.
Secondly, even if I got it working well, it's not really a great fit for what this library is about. In the intro, I specifically mention that promises and streams are all about asynchronous values. I.e., if there's no value to be delivered, then the notion of a promise/stream seems strange.

If this issue was about functionality, I'd think harder about a workaround. But, since it's about elegance, ease, and clarity, I'm seeing arguments both ways.

[hexonaut]

TBH I use void promises all the time. Very useful if you are only interested in the success or failure of an operation. My quick solution was to just define a dumy type to represent a void promise:

typedef VoidPromise = Promise<Dynamic>;

That way users of the promise will understand the return value is garbage.