# SE-0328: Structural opaque result types

**URL:** <https://forums.swift.org/t/se-0328-structural-opaque-result-types/53248>\
**Category:** Proposal Reviews\
**Created:** [November 2, 2021, 6:33pm UTC](https://forums.swift.org/t/se-0328-structural-opaque-result-types/53248 "2021-11-02T18:33:53Z")\
**Posts on this page:** 1\
**Showing post:** 15

<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:** [November 3, 2021, 2:51pm UTC](https://forums.swift.org/t/se-0328-structural-opaque-result-types/53248/15 "2021-11-03T14:51:16Z")

</div>

Thank you for the precise summary of previous conversation ([here](https://forums.swift.org/t/discussion-easing-the-learning-curve-for-introducing-generic-parameters/52891/16)). I appreciate it 🙇‍♂️

I think we should consider that the addition of `T<some P>` will increase the number of functions that takes reverse generic argument. For example, consider `Array<some Numeric>`. Calling `append` method must require reverse generic argument.

```swift
var array: Array<some Numeric> = [0, 1, 2, 3]
// it requires reverse generic argument
array.append(...)

```

With more examples of reverse generic argument, this proposal will strengthen the argument that `some P` should be used for reverse generic arguments, even if we rule out to use bare `some P` in argument position.

---

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