# \[Pitch\] Implicit member expressions for function-typed parameters

**URL:** <https://forums.swift.org/t/pitch-implicit-member-expressions-for-function-typed-parameters/87892>\
**Category:** Pitches\
**Created:** [June 30, 2026, 4:38pm UTC](https://forums.swift.org/t/pitch-implicit-member-expressions-for-function-typed-parameters/87892 "2026-06-30T16:38:21Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![vitamin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/vitamin/32/11098_2.png) [@vitamin](https://forums.swift.org/u/vitamin)\
**Post date:** [July 1, 2026, 7:48pm UTC](https://forums.swift.org/t/pitch-implicit-member-expressions-for-function-typed-parameters/87892/10 "2026-07-01T19:48:17Z")

</div>

> [@xwu](#):
>
> I think @mayoff's point is that "implicit member expressions" have rules about what _should_ be inferred and that what you describe is not that--i.e., that your pitch is for inference that is outside what the leading dot _means_ in Swift and not a question of whether it _can_ be done technically.

Thanks for bringing up the topic of rules about what the compiler should infer. Apologies in advance for the long reply (just trying to be thorough, and hopefully write material that would become part of the official proposal).

**EDIT** : After additional research today, adding an "Addendum" section at the end of this post to discuss several key findings. Will update the pitch document to provide a comprehensive overview later.

Adding to the description of existing behavior that Rob provided, below are ~~two~~ three sections to explain the current proposal:

- [Rules about inference](#rules-about-inference): What I have been able to gather about the apparent rules of implicit member expressions from documented sources, with comments on how the proposed solution relates to them. (Please reply with any additions/corrections)
- [Solution modeled on optional handling](#solution-modeled-on-optional-handling): How the proposed solution was modeled on (and in a minor way, improves upon) the existing handling of Optionals.
- [EDIT: Addendum—July 2](#edit-addendum-july-2): Discussion of an additional rule and ongoing work; new diagnostics added to PR.

## Rules about inference

1. Swift's API design guidelines [Fundamentals](https://www.swift.org/documentation/api-design-guidelines/?utm_source=chatgpt.com):

2. Swift's official docs on [Implicit Member Expressions](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/expressions/):

3. Swift's official docs on [Chained Implicit Member Expressions](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/expressions/):

4. [SE-0287: Extend implicit member syntax to cover chains of member references](https://forums.swift.org/t/allow-chained-member-references-in-implicit-member-expressions/32829)[Allow chained member references in implicit member expressions](https://forums.swift.org/t/allow-chained-member-references-in-implicit-member-expressions/32829) followed a "mental model" rule:

## Solution Modeled on `Optional` handling

When I developed this proposal, I started by looking at how Optionals are handled as an exception to the "member of the contextual type rule". Consider:

```swift
struct Foo<T> {
    init(_ t: T) { }
    init<P>(_ t: @escaping @Sendable (P) -> T) {}
}

enum X { case a }

let a1 = Foo<X?>(.a) // ✅ ... even though:
let a2 = X?.a // ❌ Type 'X?' has no member 'a'

```

Inside SEMA, `Foo<X?>(.a)` works because of the `DeclViaUnwrappedOptional` path that "looks through" to find the return type of the function, `(Payload) -> X`, which is produced by `Optional<X>.some`, even though `.a` is not a member of it.

The proposed solution copies that existing "rule-breaking" `DeclViaUnwrappedOptional` path and applies it more broadly to any function type that returns the contextually expected type—including this scenario also involving `Optional`:

```swift
let b1 = Foo<X?>(.some) // ❌ Member 'some' expects argument of type 'X'
let b2 = Foo<X?>(X?.some) // ✅ (why should X?.some work but not .some?)

```

... which is no longer an error under the proposed solution:

`let b1 = Foo<X?>(.some) // ✅ (nice!)`

For detail, `ImplicitMemberOnFunctionType` pathway for this example is essentially:

- `choose(.some)`
- where `func choose(_: X?) -> Int` / `func choose<P>(_: (P) -> X?) -> String`)  
selects the function overload —  
`let picked: String = choose(.some)` type-checks.
- such that `.some` resolves to `X?.some : (X) -> X?`,  
binding `P = X`,  
(identical in mechanism to how it'd work for `.b` in the other examples).

## EDIT: Addendum—July 2

### Additional rules discussion: TypeChecker.md

TypeChecker.md in `swift/docs` has that:

> The Swift language contains a number of features not part of the Hindley-Milner type system, including constrained polymorphic types and function overloading, which complicate the presentation and implementation somewhat. **On the other hand, Swift limits the scope of type inference to a single expression or statement, for purely practical reasons: we expect that we can provide better performance and vastly better diagnostics when the problem is limited in scope.**

Comment: a primary goal of this proposal is to avoid running afoul of this rule. This proposal must not open a Pandora's box of expressivity with currying, point-free-style expressions, or self-referentiality.

Fortunately, the proposed solution holds the line and indeed "limits the scope of type inference to a single expression or statement." Here, the leading dot means what it has always meant: a value of the contextual type. This proposal doesn't change that; it only updates the compiler to properly respect the fact that an unapplied enum-case constructor or static factory _is a value of function type_:

- `.a` with `X` → `X.a`, a value of `X`.
- `.b` with `(Int) -> X` → `X.b`, a value of `(Int) -> X` -- because the case constructor `X.b` _literally denotes a function_ `(Int) -> X`

Nothing is wrapped or looked-through; the reference is a function value. ∎

### Ongoing work

As an ongoing effort now, a systematic effort to exhaust possible "gotchas" is underway:

- currying edge cases
- diagnostics vis-à-vis structural ambiguity
- stress testing of lookup (guard against "point-free" style issues)

So far this testing has two results:

- The proposed solution (in current PR) preserves the rule that dot syntax names a value of the contextual type by looking at the return type. It never inspects or captures the parameters. As a result, it has not been able to be fooled by "receiver/point-free/uncurry" types of traps. They all require the parameter list to be in play, but it never is.
- A couple of gaps were found in diagnostics, which have now been corrected on the PR. Essentially we are just porting over the pre-existing diagnostics already given for certain scenarios with the explicit forms of the same member expressions, which this proposal now allows to be expressed implicitly.

Will continue to check various "trap" scenarios and if anyone has a clever one that can refute the proposed solution, I'm happy to close out the PR and withdraw the pitch.

Can provide the list of "traps" already tested in a followup post if desired.

## In Conclusion

Please reply if I'm reading any of this incorrectly or you are aware of any other rules that would argue against (or support) the proposal. Thanks.

---

_[View the full topic](https://forums.swift.org/t/pitch-implicit-member-expressions-for-function-typed-parameters/87892)._