Present: tmandry, TC, yosh, eholk, vincenzo
.await PRTC: We discussed this in the meeting on Monday. There seem to be tradeoffs here. At a minimum, it probably needs a crater run.
vincenzo: Looks like that the reason is that we could simplify the API:
from:
assert_eq!(shared.as_ref().await.id, 4);
to:
assert_eq!(shared.await.id, 4);
Sure why not? I am not able to see what is the impact of possible api that relay on as_ref()?
tmandry: Can this break existing code? Is this a change we need to consider over an edition?
vincenzo: We should be careful about this, but if it's compatible we should do it.
tmandry: There's an argument from consistency with method dispatch.
TC: I wonder if we would feel the same way if we had gone with prefix await or postfix space syntax.
yosh: I think we would. Striving for async Rust to be like sync Rust, it could make sense.
.await"yosh: https://github.com/rust-lang/rust/issues/111546#issuecomment-1557577198
// sync
fn johns_id() -> Option<u32> {
USER_IDS.get("John Doe").copied()
}
// async, current
fn johns_id_no_autoref() -> Option<u32> {
USER_IDS.force().await.get("John Doe").copied()
}
// async, proposed
fn johns_id_with_autoref() -> Option<u32> {
USER_IDS.await.get("John Doe").copied()
}
Autoref on await would let us do:
let mut iterator = AsyncCountingIterator::new();
let first = iterator.await;
let second = iterator.await;
instead of
let mut iterator = AsyncCountingIterator::new();
let first = iterator.next().await;
let second = iterator.next().await;
tmandry: The other consistency angle I'm thinking of is into_iterator. Do we do it there?
let foo = vec![];
// Calls <Vec<()> as IntoIterator>::into_iter():
for x in foo {}
// Calls <&Vec<()> as IntoIterator>::into_iter():
for x in &foo {}
TC: To summarize, when the language uses into_iter, as in for x in y syntax, it doesn't do autoderef. Since Iterator and for is a similar effect to Future and await, this is a strong analogy.
tmandry: Agree with that summary.
The original example in the issue was:
use core::future::IntoFuture;
use futures::future::{ready, Ready};
struct Foo;
impl IntoFuture for &Foo {
type Output = u32;
type IntoFuture = Ready<u32>;
fn into_future(self) -> Self::IntoFuture {
ready(2)
}
}
#[tokio::main]
async fn main() {
assert_eq!(Foo.await, 2);
}
(&USER_IDS).await
tmandry: People on the lang team have in the past "threatened" to add .ref to make that nicer.
yosh: A different way to reason about it could be we should tweak how into_iterator works. (Not actually proposing we should though, but it's an option.)
tmandry: It does make me think here, "why couldn't the user just do an impl IntoFuture for Foo"?
yosh: That seems to work?
eholk: that consumes the Foo though. In the example on the issue the thing being awaited is a static so we don't want to (can't?) consume it.
tmandry: Because of postfix .await, it's more of a pain to explicitly take a reference. Some lang team members have talked about .ref or similar. But we should maybe put more weight on the method dispatch analogy based on this.
TC: What would be the tradeoffs of doing autoderef on for loops?
tmandry: It would be confusing.
eholk: With for loops there's a convenient place to put the ampersand.
TC: It seems maybe unprincipled to make a decision based only on the syntax that we chose for await rather than its semantic similar to other things in the language.
TC: Do any of the downsides that tmandry mentioned about for apply to .await?
yosh: Are there any general statements we can make about postfix syntax?
TC: E.g., what if we had postfix .for(..) { .. }? How would we feel about that and about the tradeoffs that tmandry raised there?
tmandry: It does feel fine to lean on the syntax for deciding how to look at this.
eholk: .await feels like a method call. It's not, but it feels that way.
TC: Interesting aside, during the discussions about choosing the await syntax, the fact that postfix dot looked like a field access or method call was one of the downsides people noted.
tmandry: It seems like we need to do a crater run. It's definitely doing to need an FCP from the lang team.
TC: Do we think that t-types will have a feeling on this?
tmandry: Yes, that's a good point, we should collect feedback there. It's be a good stance to say that we want this but that we're cautious about problems.
TC: +1
yosh: Thinking about what you said, TC, about it not being principled… I do think we want principled designs. If we decide that .await should do deref, then we should decide that all postfix syntax should probably do that. We should take that into account. That's definite 100% RFC material and lives on the lang team.
TC: +1
tmandry: +1, there should be some principle.
eholk, vincenzo: +1
TC: Postfix match syntax… we couldn't do autoderef for that, that would be weird.
tmandry: Right.
yosh: Is the binding mode thing on match related to autoderef?
TC: Not really, it follows a different set of rules.
eholk: Are these under discussion on the language side?
tmandry: We have discussed postfix match.
yosh: I know of two examples where postfix match is being considered. Here are two examples:
// for-loops
for match in my_iter {
x => {}
y => {}
}
// try statements
try { .. } match { .. }
tmandry: That's different than what I think of with respect to postfix match. I think of .match { .. }.
Future::maptmandry: We don't really have time to dive into the second issue.
TC: Maybe we could discuss the items from last week for the people who weren't here.
TC: Here's that meeting: https://hackmd.io/LfWcsTSYTPK5TuORJ4l22g
(Discussion about Future::map.)
TC: I did have a thought about this after the meeting last week…
TC: Maybe we should just add this method to a separate trait (that could later be implemented by other things like Option). So rather than:
pub trait Future {
fn map<U, F>(self, f: F) -> Map<Self, F>
where
F: FnOnce(Self::Output) -> U;
}
We would add:
trait MapOnce<T> {
type Wrapped<U>;
fn map<U, F>(self, f: F) -> Self::Wrapped<U>
where
F: FnOnce(T) -> U;
}
And we would add an appropriate blanket impl.
(Some discussion followed.)
(The meeting ended here.)
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe