One of the reasons that placeholders for generic bases was left out of this proposal is that I myself am more skeptical of the utility there, and this point raises another useful objection. Currently, since standalone placeholders are disallowed and generic bases must be specified, it is (hopefully) clear to the author that any usage of placeholders in property signatures is a commitment to a specific concrete type.
That is, if generic bases were allowed to be placeholders, the property declared as:
let publisher: _<Int, _> = Just(makeValue()).setFailureType(to: Error.self).eraseToAnyPublisher()
will have its type visible to clients as AnyPublisher<Int, Error>
, and it could not be later changed to have type PassthroughSubject<Int, Error>
without an ABI/API break, whereas (with the proper additional opaque type features) a property declared as:
let publisher: some Publisher where .Output == Int, .Failure == Error = Just(makeValue()).setFailureType(to: Error.self)
could freely change its concrete type later on as long as it obeyed the some Publisher
contract.
Of course, neither of the forms above are valid today (or under this proposal). The former must be written as:
let publisher: AnyPublisher<Int, _> = Just(makeValue()).setFailureType(to: Error.self).eraseToAnyPublisher()
and the second can't even be properly expressed.
@hborla's succinct summary is, IMO, a great distillation of the scope of this feature:
This feature doesn't attempt to introduce any new fundamental capabilities/expressive power to the type system (as opaque types did), it only provides more specificity in how users can direct type inference using existing type system capabilities.
I suspect that a nomenclature shift to "inferred type" would help greatly with the understanding of this feature.
Does that appropriately address your questions/concerns, @Philippe_Hausler?