Commit 28d59ad
committed
[SWUtil] PropertyListItem: Clarify use of
The original comment that these overloads can be removed was incorrect
because the existential of `PropertyListItemConvertible` doesn't self
conform. The overloads are still needed to support collections with
heterogeneous values but nothing else and so they should be disfavored.
Turns out that some of the expressions that used to take advantage
of these overloads only work due to the solver producing a valid
solution from the "diagnostic" mode.
For example:
```
public var propertyListItem: PropertyListItem {
return .init(entries
.sorted { $0.identifier < $1.identifier }
.map {
[
"bundle-id": .plString($0.identifier),
"tags": PropertyListItem($0.tags.sorted()),
"bundle-path": .plString($0.path.str),
]
})
}
```
This expression should have been ambiguous because it can match
both `.init(any ...)` and `.init([any ...])` overloads due to an
existential conversion that is bi-directional for the closure.
For `.init(any ...)`, result of the closure is going to be erased
to existential inside of the body of the `.map` closure and for
`.init([any ...])`, this erasure is going to happen outside but
both are equally valid.init overloads that take array and dictionary1 parent f49864e commit 28d59ad
1 file changed
+11
-3
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
362 | 362 | | |
363 | 363 | | |
364 | 364 | | |
365 | | - | |
| 365 | + | |
366 | 366 | | |
367 | 367 | | |
368 | 368 | | |
369 | | - | |
| 369 | + | |
| 370 | + | |
| 371 | + | |
| 372 | + | |
| 373 | + | |
370 | 374 | | |
371 | 375 | | |
372 | 376 | | |
373 | 377 | | |
374 | | - | |
| 378 | + | |
| 379 | + | |
| 380 | + | |
| 381 | + | |
| 382 | + | |
375 | 383 | | |
376 | 384 | | |
377 | 385 | | |
| |||
0 commit comments