# \[Idea\] "fully typed patterns" and function parameter type inference for those **URL:** \ **Category:** language design\ **Created:** [July 14, 2024, 8:36pm UTC](https://internals.rust-lang.org/t/idea-fully-typed-patterns-and-function-parameter-type-inference-for-those/21175 "2024-07-14T20:36:12Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![JustusFluegel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/justusfluegel/32/12338_2.png) [@JustusFluegel](https://internals.rust-lang.org/u/JustusFluegel)\ **Post date:** [July 14, 2024, 8:36pm UTC](https://internals.rust-lang.org/t/idea-fully-typed-patterns-and-function-parameter-type-inference-for-those/21175/1 "2024-07-14T20:36:12Z")
I don't know if this is something that was discussed somewhere already but I haven't run across it yet so I am going to put it up to discussion here: How about we have a notion of "fully typed patterns", i.e. patterns from which the type can be fully inferred, and drop the necessity for providing the type for parameters in functions that are such "fully typed patterns" For an example (using a axum handler, where this pattern could be useful) ```rust // before fn handler(Json(data): Json) -> ... { ... } // with "fully typed patterns" fn handler(Json::(data)) -> ... { ... } ``` As you can see, the type here is fully given by the pattern already and as such the type annotation should be redundant. This is explicitly not proposing to drop the requirement that function parameters need an explicit type in general - only in the special case where the pattern of the parameter itself can fully specify that type. That means there should be no huge complexity cost for the type resolution process from that, as well as being fully compatible with existing code, i.e. this shouldn't be breaking. # Advantages - Less repetition in parameters of functions taking patterns # Potential disadvantages I don't think there are any huge ones but maybe - Slightly increased compile times (?) - Slightly more complex error messages - More complex to generate rustdoc maybe, since we need to figure out the concrete type for the param? I would love to hear your thoughts! ( as an aside: the name "fully typed pattern" is choosen arbitrarily by me and there is probably a better way to call it ) ---
**Author:** ![FZs](https://avatars.discourse-cdn.com/v4/letter/f/85f322/32.png) [@FZs](https://internals.rust-lang.org/u/FZs)\ **Post date:** [July 14, 2024, 9:34pm UTC](https://internals.rust-lang.org/t/idea-fully-typed-patterns-and-function-parameter-type-inference-for-those/21175/2 "2024-07-14T21:34:43Z")
One similar idea (or extension) to this I had recently is to allow a sort of type ascription inside patterns, which would (when used in a function signature) negate the need to annotate the argument type separately. For example: ``` fn foo((string, vec): (&str, Vec)) // could be written as fn foo((string: &str, vec: Vec)) ``` I don't know what the blocker is on type ascription in general (it seems to have stalled since 2016, if I looked correctly?), but maybe it could be extended to include this? ---
**Author:** ![JustusFluegel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/justusfluegel/32/12338_2.png) [@JustusFluegel](https://internals.rust-lang.org/u/JustusFluegel)\ **Post date:** [July 14, 2024, 9:55pm UTC](https://internals.rust-lang.org/t/idea-fully-typed-patterns-and-function-parameter-type-inference-for-those/21175/3 "2024-07-14T21:55:24Z")
Well I agree that type ascription in general seems like a overdue thing, but I would explicitly exclude it from this ( if this ever happens ) and keep it separate, to avoid making this more complex than it needs to be, at least for now. I think type ascription was mostly stalled because of the additional complexity which the team at the time didn't feel like time well spent to solve, although with the note that it should be picked up again later - might remember wrong here tho. ( although I agree that the tuple case in particular is a very natural extension to this ) ---
**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\ **Post date:** [July 14, 2024, 11:08pm UTC](https://internals.rust-lang.org/t/idea-fully-typed-patterns-and-function-parameter-type-inference-for-those/21175/4 "2024-07-14T23:08:59Z")
> [@JustusFluegel](#): > > ```rust > // with "fully typed patterns" > fn handler(Json(data)) -> ... { ... } > > ``` This was discussed back in 2018: [RFC: Generalized Type Ascription by Centril ยท Pull Request #2522 ยท rust-lang/rfcs ยท GitHub](https://github.com/rust-lang/rfcs/pull/2522#issuecomment-412322739) I originally was in favour, but the discussion about the feature changed my mind. My position is now that having the `: $ty` always there is the right thing. Yes, `Wrapping(x: u32)` _is_ enough to deduce that the parameter is `Wrapping`, but I no longer think that we should be making people do that deduction. The type should be directly clear, both for humans and things like proc macros. Thus I would prefer -- both here and in things like `static`s -- to instead make more convenient construction and pattern syntax, for use in places where the type is contextually clear. (Like how we have `Default::default()` already, how C++ has conversions from initializer lists, or C# added [target-typed `new` expressions](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/target-typed-new).) So, for example, rather than having ```rust fn demo(Point { x, y }: Point) // decl demo(Point { x, y }) // cal ``` if we added, say, Swift-inspired ```rust fn demo(.{ x, y }: Point) // decl demo(.{ x, y }) // call ``` We can remove a bunch of the unnecessary repetition without losing the syntatically-clear type. ---
**Author:** ![JustusFluegel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/justusfluegel/32/12338_2.png) [@JustusFluegel](https://internals.rust-lang.org/u/JustusFluegel)\ **Post date:** [July 14, 2024, 11:14pm UTC](https://internals.rust-lang.org/t/idea-fully-typed-patterns-and-function-parameter-type-inference-for-those/21175/5 "2024-07-14T23:14:50Z")
> I originally was in favour, but the discussion about the feature changed my mind. My position is now that having the `: $ty` always there is the right thing. Yes, `Wrapping(x: u32)` _is_ enough to deduce that the parameter is `Wrapping`, but I no longer think that we should be making people do that deduction. The type should be directly clear, both for humans and things like proc macros. Maybe that was unclear but I explicitly _wasn't_ proposing to allow `Wrapping(x: u32)` - I agree that makes it substantially harder to read. I think `Wrapping::(x)` is reasonable though and already works today as a pattern. ---
**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\ **Post date:** [July 14, 2024, 11:22pm UTC](https://internals.rust-lang.org/t/idea-fully-typed-patterns-and-function-parameter-type-inference-for-those/21175/6 "2024-07-14T23:22:15Z")
> [@JustusFluegel](#): > > I think `Wrapping::(x)` is reasonable though and already works today as a pattern. That doesn't change how I think about it here. I still want the full type after the `:`. To use your example, I'd rather ```rust fn handler(.(data): Json) -> ... { ... } ``` instead. ---
**Author:** ![JustusFluegel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/justusfluegel/32/12338_2.png) [@JustusFluegel](https://internals.rust-lang.org/u/JustusFluegel)\ **Post date:** [July 14, 2024, 11:26pm UTC](https://internals.rust-lang.org/t/idea-fully-typed-patterns-and-function-parameter-type-inference-for-those/21175/7 "2024-07-14T23:26:22Z")
I don't know if I agree with you there (feel free to try to convince me tho if you want to ๐Ÿ™‚ ) but if that syntax was supported I would probably prefer ```rust fn handler(_(data): Json) -> ... { ... } ``` over ```rust fn handler(.(data): Json) -> ... { ... } ``` since `_` already works as a "inferred" identifier in other places in rust today and `.` feels pretty unintuitive to me here, that might just be me tho. ---
**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\ **Post date:** [July 15, 2024, 12:20am UTC](https://internals.rust-lang.org/t/idea-fully-typed-patterns-and-function-parameter-type-inference-for-those/21175/8 "2024-07-15T00:20:35Z")
> [@JustusFluegel](#): > > I would probably prefer > > `fn handler(_(data): Json) -> ... { ... }` That's the big bikeshed for the feature, yup ๐Ÿ˜› I agree that `_ { x, y }` makes some sense, but `_(data)` in particular it's less obvious, since that's not actually type position, and `_` is only inferred _type_ today, not "inferred identifier". Per [https://rust-lang.github.io/rfcs/1506-adt-kinds.html#tuple-structs](https://rust-lang.github.io/rfcs/1506-adt-kinds.html#tuple-structs), ```rust let x = Wrapping(4); ``` is a function call, so ```rust let x: Wrapping = _(4); ``` would be an inferred function call, sorta? At that opens up all kinds of expectations that people could have that wouldn't actually make sense. Thus I've been trying out the Swift-style `let x: Ordering = .Less;` style syntax in my examples (as opposed to `let x: Ordering = _::Less;` that's also often used) to see how it feels. Probably not worth trying to solve that bikeshed in this thread, though. The important part of my post is the "infer in the pattern or expression, keep the type" direction, not the syntax for what that should look like. ---
**Author:** ![Yokin](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/yokin/32/12030_2.png) [@Yokin](https://internals.rust-lang.org/u/Yokin)\ **Post date:** [July 17, 2024, 4:20am UTC](https://internals.rust-lang.org/t/idea-fully-typed-patterns-and-function-parameter-type-inference-for-those/21175/9 "2024-07-17T04:20:31Z")
> [@scottmcm](#): > > ```rust > fn demo(Point { x, y }: Point) // decl > > demo(Point { x, y }) // cal > > ``` > > if we added, say, Swift-inspired > > ```rust > fn demo(.{ x, y }: Point) // decl > > demo(.{ x, y }) // call > > ``` > > We can remove a bunch of the unnecessary repetition without losing the syntatically-clear type. I like this a lot but I think there's one problem that it wouldn't solve, which is that sometimes you run into really complex types and it would be nice if you could localize the ascription to each variable individually. For example something that I'm working on involves parameter types like this: ```rust .on_begin(|Fetch((mut pos, time, /*etc*/)): Fetch<(Each, Res