A wild Swift evolution pitch appears! It overhauls some fundamental Standard Library constructs to allow building things using noncopyable types. It's super effective, I hope
@ctietze This is primarily because insertions and removals have complexity that’s linear in the size of the array — they have to slide existing items to make room for a new one or to close gaps after a removal.
Arrays have benefits on small sizes because they are compact. Beyond a couple thousands or so items, this advantage is entirely eclipsed by all these movement costs: they become unbearably slow.
[1/2]
#Swift tip: if you need to bind a non-optional value to a temporary variable inside a conditional statement, you can use case let, e.g:
if indexPath.section < sections.count,
case let section = sections[indexPath.section],
indexPath.row < section.rows.count,
case let row = section.rows[indexPath.row],
row.isEnabled
{
...
}
This saves you needing to split up the condition into multiple statements, and polluting the local namespace with temporary variables you don't need again.
@ctietze@nicklockwood Just popping in to note that there is only one String.Index type, shared across all string views. (The indexing model would in fact be simpler to understand/implement if each view had its own index type, but that was deemed too inconvenient. Nevertheless, creating named wrapper types to implement ad hoc subtypes is a highly useful technique, and it should be encouraged and normalized, rather than ridiculed.)