I might be a little bit late to the party,
Well, if the party is still going on after three years, it must be a good one... ;-)
Is it true that nothing newer has happened on this issue after this message?
Not entirely sure, but if you still experience the problem, it apparently has not changed. I also still have #halt-s in the Promise methods in my working images so that I can deal with errors.
> The behavior of non-local exits from unwind contexts is undefined in the Smalltalk ANSI standard (just like resume: or return: in a defaultAction, or not sending resume: or return: in an on:do: exception handler at all -- VA Smalltalk interprets that as resume, while Squeak does return, for example).
I don't understand the context of this note, but speaking in terms of Squeak,
To implement it "Squeak-conformant" is probably enough. In 2020 it was not long ago that I worked with VA Smalltalk and I was regularly annoyed by non-portable (not "ANSI-conformant") code. The chances that somebody will want to use the Squeak implementation of Promises in another Smalltalk are probably quite slim. Nevertheless, I have made it a habit to always use return: or resume: in handler blocks.
One additional note: What should happen if you terminate the active process from a promise (or do the same from the outside)? Should this also reject this promise, or should it be scheduled later again? However, this is likely a different story, so let's not add another dependency to this issue.
Agreed. Intuitively it sounds right to eventually reject something that was aborted. But since we do have multi-processing/-threading, the Promise might yet be fulfilled by another process. Or not... depends on the application. We might not be able to find a general answer that suits all use cases. You could also think about rejecting unfulfilled promises when they are garbage-collected... but JavaScript does not do that either, as far as I know.
Maybe the answer is: just don't do that in your application. :-)
Kind regards,
Jakob