# \[Pitch 2\] Light-weight same-type requirement syntax

**URL:** <https://forums.swift.org/t/pitch-2-light-weight-same-type-requirement-syntax/55081>\
**Category:** Pitches\
**Created:** [February 3, 2022, 5:20pm UTC](https://forums.swift.org/t/pitch-2-light-weight-same-type-requirement-syntax/55081 "2022-02-03T17:20:44Z")\
**Posts on this page:** 1\
**Showing post:** 151

<div class="post-metadata">

**Author:** ![ExFalsoQuodlibet](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@ExFalsoQuodlibet](https://forums.swift.org/u/ExFalsoQuodlibet)\
**Post date:** [February 21, 2022, 8:34am UTC](https://forums.swift.org/t/pitch-2-light-weight-same-type-requirement-syntax/55081/151 "2022-02-21T08:34:13Z")

</div>

> [@ben-cohen](#):
>
> It is in this context that I am laying out my claim: opaque **result** types with arbitrary constraints are probably so marginally useful that it is a very low priority to add them to the language.

I can't argue with that.

I'm honestly getting a little confused about opaque types in general. I might be wrong but I see the use cases of opaque types (parameters, result, structural et cetera) as a sugary lightweight alternative to generic parameters. And I support the pitch also because I find the excellent example, very well put by @Karl

> [@Karl](#):
>
> ```swift
> func doSomething(_ items: some Collection<Int>)
> 
> // Oh no! We need Index to conform to Hashable!
> // It's just a simple matter of... oh...
> 
> func doSomething<C>(_ items: C) where C: Collection, C.Element == Int, C.Index: Hashable
> 
> ```

to not be particularly problematic: if I ever found myself in the position to teach this, I'd do it in 2 steps, first desugar the opaque parameter, then add the additional constraint.

So, if opaque types are a lightweight sugar form of the more complete and powerful generics signature, I'm not concerned about the expressivity limitation related to the usage of the new syntax (introduced by this pitch, together with an expressivity addition) in the return position of a function, because the actual missing feature is [reverse generics](https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--reverse-generics), and this pitch doesn't preclude future work on that, while being very useful in itself.

---

_[View the full topic](https://forums.swift.org/t/pitch-2-light-weight-same-type-requirement-syntax/55081)._