-
Notifications
You must be signed in to change notification settings - Fork 47
rename Deferred
to Eventually
?
#18
Comments
Any movement on this? |
I haven't written any code, if that's the question. :) Are we still interested in changing it (and possibly renaming the project from Deferred, since that name would no longer apply)? There's been another quarter of usage and work on the project since the issue was opened, and things seem a bit more solid now. |
It's a branding choice at this point. Re-open for any concerns. |
Agreeing with closure, but with some closing thoughts. :) Looking at this with fresh eyes - deferred is a weird name. It's like, "Yeah, we could do it now, but we decided to put it off." We could rename the type without renaming the library containing it, so it needn't affect library branding. That said, you quickly become used to the |
We might be able to revisit the network of names in the Swift 3 time period. If we don't get better existentials (or even if we do), we'll have to reconsider the names of |
I think the name would be more suggestive of the semantics if
Deferred
were namedEventually
.If we separate the future value from the ability to fill it, we'd likely have an internal
Deferred
with public "faces"Eventually<Value>
andResolve<Value>
. I'm not sold on theResolve
bit –Determine
,Fix
,Produce
,Supply
.Resolve
has the advantage that you canresolve.to(v)
, though.The text was updated successfully, but these errors were encountered: