1

I think in make a proposal about Pipe Line operators to types.

So imagine that we have a problem, you can work with one or another type that you want, is almost like that.

protocol ConfigurableGrapqhl { } /// The behavior from grapqhl

protocol ConfigurableRestfull {} /// The behavior from rest

struct Service {

     func get<T: ConfigurableGrapqhl | ConfigurableRestfull > {
              /// we can treated the behavior here
         }
}

I can think more things that we can use the operator to types

We can compose function or something like that.

PipeIdea<T, U> = (data: T | U) -> U
2

This is on the “Commonly Rejected Changes” list:

  • Disjunctions (logical ORs) in type constraints: These include anonymous union-like types (e.g. (Int | String) for a type that can be inhabited by either an integer or a string). "[This type of constraint is] something that the type system cannot and should not support."
2 Likes
3

Wouldn’t a type that’s either an Int or String be described thusly in Swift?

enum IntOrString {
    case int(Int)
    case string(String)
}
4

Or something more generic,

enum Either<T, U> {
  case lhs(T)
  case rhs(U)
}

// Either<Int, String>

You could do some cool stuff by making that conform to the expressible protocols for trivial types like these :smile:
let x: Either<Int, String> = 316
(However you can’t have something like Either<Int, UInt> because of conflicting conformance...)

1 Like
5

This is where synthesized forwarding conformances would be most helpful, because to do this by hand you'd have to write the conditional conformances for both ExpressiblByX where T: ExperessibleByX and where U: ExpressibleByX.

And as you said, you can't even handle the case where both types are ExpressibleByX, even when you could disambiguate at the callsite using as.

1 Like