# Structural opaque result types

**URL:** <https://forums.swift.org/t/structural-opaque-result-types/50998>\
**Category:** Pitches\
**Tags:** generics, opaque-types\
**Created:** [August 6, 2021, 8:55pm UTC](https://forums.swift.org/t/structural-opaque-result-types/50998 "2021-08-06T20:55:25Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![ensan-hcl](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ensan-hcl/32/15186_2.png) [@ensan-hcl](https://forums.swift.org/u/ensan-hcl)\
**Post date:** [August 7, 2021, 1:18am UTC](https://forums.swift.org/t/structural-opaque-result-types/50998/2 "2021-08-07T01:18:07Z")

</div>

It's great!

But I doubt this point.

> [@bdriscoll](#):
>
> If the result type of a function, the type of a variable, or the result type of a subscript is a function type, that function type can contain arbitrary structural opaque result types. For example, `func f() -> () -> some P` and `func g() -> (some P) -> ()` .
> 
> Note that the closure value produced by calling `g` in the above example is itself uncallable. It has type `(some P) -> ()` , meaning it takes an opaque result type as an argument. That argument has some concrete type, `T` , determined by the body of the closure. Obviously the client cannot call the closure with a value of some other type, `U` . However, the client also cannot call the closure with a value of type `T` . If they were able to, then they would be depending at the source level on the concrete type to remain fixed, which is one of the things opaque result types are designed to prevent.

[Edit]  
I've misread. This is only an example which closure with opaque result type argument can be called.

~~IIUC, your argument is that, there is no way to call `g`, and therefore should be explicitly disallowed. But it's not true.~~ I previously [posted about 'reverse generic argument types'](https://forums.swift.org/t/reverse-generics-for-argument-type/47842). Consider following closure:

```Swift
var closure: (some Numeric) -> () = { (value: Double) in print(value) }

```

`some Numeric` is actually `Double`, but it doesn't matter. We have information about `some Numeric`: it conforms to `ExpressibleByIntegerLiteral` and it has `static` property `zero`. Therefore, even though we cannot call this closure with `Double`, **we can still use this closure** like this:

```Swift
closure(42) // 42
closure(21) // 21
closure(.zero) // 0

```

Actually similar behavior has been in the current Swift already. You can try how it works:

```Swift
protocol Printer {
    func print(value: Self)
}
extension Double: Printer {
    func print(value: Double) { Swift.print(value) }
}
let d: some (Numeric & Printer) = 42.0
let closure = d.print
// you can still call this closure!
closure(42.0) // error (since type is opaque)
closure(42) // OK (from ExpressibleByIntegerLiteral)
closure(.zero) // OK (from AdditiveArithmetic)

```

Like this, having `g` doesn't cause any problems. You can still call the closure, and use it. There is no reason to explicitly disallow it.

---

_[View the full topic](https://forums.swift.org/t/structural-opaque-result-types/50998)._