New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
optional type parameter for newPromise() #671
Conversation
I know that some people in the server space do this, but I always found those
Which, funny enough, is what |
Sure it is. Codable uses it heavily, both in the API ( And in fact the last time we did something like this (in 94c21b6) it was at the suggestion of some members of the standard library team. TL;DR: the prior art for The concern about the factory method is reasonable, but as this is intended as a semver minor we can't fix it here. I'm +1 on the idea of changing to a construct for SwiftNIO 2.0 though. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left a note in the diff about the naming, which I don't love.
To @helje5's point though, if you and or @normanmaurer are interested in changing the way we construct EventLoopPromise
objects for SwiftNIO 2, I might suggest deferring this change until then.
Sources/NIO/EventLoop.swift
Outdated
@@ -318,7 +318,7 @@ extension EventLoop { | |||
} | |||
|
|||
/// Creates and returns a new `EventLoopPromise` that will be notified using this `EventLoop` as execution `Thread`. | |||
public func newPromise<T>(file: StaticString = #file, line: UInt = #line) -> EventLoopPromise<T> { | |||
public func newPromise<T>(type: T.Type = T.self, file: StaticString = #file, line: UInt = #line) -> EventLoopPromise<T> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the name type
here. It sits weirdly with me: it's not the type of the promise, it's the type of what it contains. Not sure what the better name choice is though: resultType
, maybe? Or futureResult
? Or producing
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Lukasa makePromise<T>(for type: T.Type = T.self)
? that reads okay: 'make promise for integer'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, in 1.0 obviously newPromise
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Lukasa updated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would makePromise<T>(of type: T.Type = T.self)
be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems I'm also late to the party here, and wanted to suggest of
as well when I was reading the PR. "a promise of string (in the future)" somehow reads better than "a promise for string (in the future)". Your call tho.
// Overall +1 though! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can still change it, it's not released. Let's page stdlib folk for API guidance, CC @airspeedswift / @lorentey
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, we now landed on newPromise(of: T.Type = T.self)
because 'making a promise of a type' is more grammatical than 'making a promise for a type' --> #672
@Lukasa / @normanmaurer I'm open to opening up |
I'm happy enough with that as a compromise position. |
Motivation: When creating new promises I always find it very frustrating to type the `: EventLoopPromise<Type>` type annotation but it's necessary for the compiler to know type the promise will be fulfilled with. Modifications: allow an optional `for: SomeType.self` parameter for `newPromise` as let p = eventLoop.newPromise(for: Int.self) is much easier to type than let p: EventLoopPromise<Int> = eventLoop.newPromise() Result: easier to write code
8a1bd4c
to
4e6d068
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have reviewed this the way I know best: by looking at the real change, and then trusting the compiler will punish you if you screwed any of the rest of it up.
Uh.
I mean.
+1 LGTM.
Motivation:
When creating new promises I always find it very frustrating to type the
: EventLoopPromise<Type>
type annotation but it's necessary for thecompiler to know type the promise will be fulfilled with.
Modifications:
allow an optional
for: SomeType.self
parameter fornewPromise
asis much easier to type than
Result:
easier to write code