Syntax sugar for turbofish/generics

[zackw]

@scottmcm

I interpreted the post to say that you could do something like

impl Trait for Struct<fresh T>

to declare a named param at the point of first use.

That's not quite what I had in mind; I was imagining something more like Python's TypeVar. The point would not just be to shorten individual impl block heads, but to factor out repeated trait bounds.

A simple, real example from my own code:

trait DmOp: Sized { ... }

struct Request<Op: DmOp> { ... }
struct Response<Op: DmOp> { ... }

impl<Op: DmOp> Request<Op> { ... }
impl<Op: DmOp> Response<Op> { ... }

unsafe impl<Op: DmOp> rustix::ioctl::Ioctl for Request<Op> { ... }

could become something like

trait DmOp: Sized { ... }
typevar Op: DmOp;

struct Request<Op> { ... }
struct Response<Op> { ... }

impl Request<Op> { ... }
impl Response<Op> { ... }

unsafe impl rustix::ioctl::Ioctl for Request<Op> { ... }

I imagine this would be handy any time there's a complex trait bound that needs to be written in many places.

(Note: This is meant to be strictly shorthand - the semantics of the second example are to be exactly the same as the semantics of the first example. I brought this concept up once before and the discussion went straight into the weeds because people thought I was proposing something with semantic implications.)

@josh

we could pick a new, unambiguous syntax for postfix type ascription on expressions, which would also have the advantage of supporting .into(). By way of example but not meant for syntax bikeshedding (since the syntax is less important than the concept), .as(u32). (That doesn't solve all cases of turbofish, but it solves many.)

While I like the idea of an unambiguous postfix type ascription notation, it doesn't help with size_of.

I have the size_of case on the brain because I have been writing code that needs to use size_of and align_of a whole lot. size_of is a generic function where you always have to supply the generic parameter explicitly, and there are no normal arguments. To me, the turbofish feels extra annoying in the context of such functions, because it's not just an escape hatch for them, it's the only way to use them. Compare size_of::<c_int>() with sizeof(int) -- four extra characters to type (six counting the underscores) and all of them require the shift key.

Both the "nix the turbine" and the "square brackets instead of angle brackets" suggestions are motivated by this situation. size_of[c_int]() is quite a bit easier to type on my keyboard, and size_of[c_int] would be even smoother, if we could manage it.