Reverse generics for argument type?

[Moximillian (Mox)]

@xAlien95

but it would be quite unusual to provide such a function in a module for the sake of making the parameter type private . If you want the parameter type to be private, then the function declaration should most likely be private too.

One of the key motivations for opaque types in return position was that library authors could hide the internal implementation details and instead only provide a constraint, so that library could evolve internally without breaking the API. I wonder if similar possible use case could exist for the function parameter position as well. Although maybe those cases can already be solved with some other way, like just using regular generics...

[Nevin]

@xAlien95

Generics and protocol types are identical on the call site:

func foo<T: Protocol>(_ p: T) {}
func bar(_ p: any Protocol) {}

you can pass any Protocol -conforming type to both foo and bar , but the difference lays in the possibility to specialize the former.

I’m pretty sure the compiler can already specialize the existential-taking function. (Hopefully someone with more expertise in the compiler can say whether bar is guaranteed to be optimized equally well as foo.)

The real difference is that with generics you can tell the compiler about same-type constraints:

func foo<T: Protocol>(_ p: T, _ q: T) {
  // p and q are known to be the same type
}

func bar(_ p: Protocol, _ q: Protocol) {
  // p and q could be of different types
}

[sighoya]

@xAlien95

Who decides which types == (lhs: some Equatable, rhs: some Equatable) -> Bool can accept in argument position? It's the function == , not the caller:

@xAlien95

The declaration of == constrains both lhs and rhs to have the same type, which is the type Self of the instance (in this case the instance is p ).

You refer to the example with two Self parameters, the only constraint the callee (i.e. ==) adds to the context is that both parameters must be the same which is currently only unique for the same variable or different aliases to the same variable.

But == doesn't specify what Self has to be for a type, that is specified by the caller, in our case it was specified by another callee with name Private which was executed in the caller.

@Dante-Broggi

@sighoya

I disagree. But maybe the term existential is redefined in Swift context, but this would lead to more confusion for users coming from other languages already knowing existentials.

So, I believe that this side discussion is fundamentally about a disagreement over the definition of "existential".

IIUC, your definition of "existential" is similar to:

a value of an existential of protocol P is a value v for which there exists a type T , such that v is of type T and T conforms to P .

Under this definition the value boxed in any P and both possible extensions of some P are existentials.

However, IIUC the definition of "existential" in general use in the Swift community is similar to:

a value of an existential of protocol P is a value b which contains a value v for which there exists a type T , such that v is of type T and T conforms to P , and b contains proofs of those statements about v .

Under this definition, any P , but not the value boxed in it, is an existential, but some P is not, because the proofs for some P are not stored in the value, but in the context.

First I wouldn't call a value an existential, this is more kinded to a variable.
Second, we could also store the proofs of some P inside the value of some P and unwrap the existential behind, but why we should do so if there is the option to optimize the boxing of some P out by simply replacing the box with the underlying type.

Yes, I see your point.
The Swift definition of existentials is more related to implementation details, my is more of abstract nature. So you are mostly correct with your conclusion.

[ensan-hcl (ensan)]

@xAlien95

No, I'm using any to refer to protocol types as the Swift Programming Language Guide calls them. Generics and protocol types are identical on the call site:

func foo<T: Protocol>(_ p: T) {}
func bar(_ p: any Protocol) {}

you can pass any Protocol -conforming type to both foo and bar , but the difference lays in the possibility to specialize the former.

Is it really identical? Current behavior is not totally the same. Is the conformance also the feature that would be achieved in the future Swift? (I know it's true for Error)

// Non-Existential Type (concrete type)
let value1: Struct= Struct()
// Existential Type (protocol as type)
let value2: Protocol = Struct()

let _ = foo(value1)  // possible
let _ = foo(value2)  // impossible, protocol 'Protocol' as a type cannot conform to the protocol itself
let _ = bar(value1)  // possible
let _ = bar(value2)  // possible

In some cases, this may not be possible, and a distinction must be made.

protocol Protocol {
    static func bar() -> Int
}

struct Struct: Protocol {
    static func bar() -> Int {
        42
    }
}

func foo<T: Protocol>(_ value: T) {
    let value = T.bar()
}

// What happens if call `foo` with protocol type
// `Protocol` doesn't have any implementation
let value: Protocol = Struct()
foo(value)