Open Lukasa opened 5 years ago
An Array carries its type around, so it'd be a stretch to share ownership here. But Swift does not have a convention that conversions that can cause allocations need to be explicit. The same is true for concrete type -> protocol.
This is definitely my lack of understanding here, but there are some cases in which this conversion does not need to allocate.
Storing [(String, String)]
in a variable of [(name: String, value: String)]
: allocates.
Storing [S]
in a variable of [P]
where protocol P
and struct S: P
: allocates.
Storing [S]
in a variable of [Super]
where class Super
and class S: Super
: does not allocate.
What don't I understand about why subclasses don't need a reallocation?
I'm not saying this change can't be done, and the class case is a good point. I'm just saying "it should not be possible to assign the array of one type to a variable of the other" is not something that Swift plans to do. We had piles of complaints when [S]
to [P]
didn't work, even with that justification.
Oh sure, I totally understand that that's a genie that cannot be put back into the bottle.
I should note that this is low-priority for us: the case where we hit this issue is easily resolved and I'll be putting a patch up soon to fix it.
Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler, Standard Library | |Labels | Bug, Performance | |Assignee | None | |Priority | Medium | md5: cc552939b1fbd98ddc37640577572eddIssue Description:
The following code, when run, allocates 200,000 transient
_ContiguousArrayStorage
objects:The allocation stack is
The issue appears to be that the cast from
[(String, String)]
to[(name: String, value: String)]
triggers an allocation and copy, despite the fact that the two types are sufficiently close to identical that the compiler will simply let you assign one to the other.Either this should not allocate, or it should not be possible to assign the array of one type to a variable of the other.