Return_type_notation on functions with arguments does not compile

I understand that async traits MVP is supposed to get stabilized in 2023 and I have looked at a couple of current recommendations specifically on how to deal with marking return type of Future as Send for spanned tasks within generic functions. I understand that both of the suggestions will be part of MVP later this year. However, I have run into a problem making one of those examples to work.

a) Failed Example uses return_type_notation feature gate

  • Playground
  • ERROR: error: return type notation is not allowed for functions that have type parameters

b) Working Example uses return_position_impl_trait_in_trait feature gate

I am running on nightly 2023-06-27 due to latest nightly having an issue with proc-macro2 compilation

rustup default nightly-2023-06-27

Does return_type_notation has an inherent limitation which does not appear to be mentioned in the MVP blog or I am missing a trick to get it to work?

Additional background:

I am researching a general purpose stock exchange connector, think FIX protocol but with binary wire serializer ex: SoupBinthat can establish and maintain connectivity, heartbeats, etc to an arbitrary stock exchange. The idea is to use generics, traits, and data model to wire a client and service socket that can speak in terms of protocol specific message struct's instead of byte slices and because there are many proprietary protocols it would make sense to be able to wire them by just changing the data model via generics and have a single/generic implementation of the networking layer that works across all exchanges.

The general description of the problem is I need to hand over control to the ProtocolInitHandler, one of the arguments during wiring, to send and recv a few admin messages inside the spawned task and before the application level service/recv loop kicks in, this handler is supposed to establish heartbeat handshake and check login information.

I don't think this is an intrinsic limitation, but do note that the current implementation is very very experimental and may be far from what ends up being the final MVP.

I thought that MVP is stabilizing in 17.4 which is very close and hence can't be radically different from what is in nightly.

I believe this is only for what the blog post calls MVP part 1

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.