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

[ExFalsoQuodlibet (Elviro Rocca)]

@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

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, and this pitch doesn't preclude future work on that, while being very useful in itself.