Есть ли причина, по которой назначение массива Swift является непоследовательным (ни ссылка, ни глубокая копия)?

Из официальной документации языка Swift:

Обратите внимание, что массив не копируется, когда вы устанавливаете новое значение с синтаксисом подстроки, потому что установка единственного значения с синтаксисом подстроки не может изменить длину массива. Однако, если вы добавили новый элемент в массив, вы измените длину массива. Это побудит Swift создать новую копию массива в том месте, где вы добавляете новое значение. В дальнейшем а - отдельная независимая копия массива.....

Прочитайте весь раздел Назначение и копирование для массивов в этой документации. Вы обнаружите, что когда вы замените диапазон элементов в массиве, массив возьмет копию для всех элементов.

Поведение изменилось с Xcode 6 beta 3. Массивы больше не являются ссылочными типами и имеют механизм copy-on-write, что означает, как только вы измените содержимое массива с того или другого переменная, массив будет скопирован и будет изменена только одна копия.

Старый ответ:

Как указывали другие, Swift пытается по возможности избежать копирования массивов, в том числе при изменении значений для отдельных индексов за раз.

Если вы хотите быть уверенным в том, что переменная массива (!) уникальна, т.е. не используется совместно с другой переменной, вы можете вызвать метод unshare. Это копирует массив, если у него уже есть только одна ссылка. Конечно, вы также можете вызвать метод copy, который всегда будет делать копию, но unshare предпочтителен удостовериться, что никакая другая переменная не держится в том же массиве.

var a = [1, 2, 3]
var b = a
b.unshare()
a[1] = 42
a               // [1, 42, 3]
b               // [1, 2, 3]

Поведение очень похоже на метод Array.Resize в .NET. Чтобы понять, что происходит, может быть полезно просмотреть историю токена . в C, С++, Java, С# и Swift.

В C структура представляет собой не что иное, как агрегацию переменных. Применяя . к переменной типа структуры, вы получите доступ к переменной, хранящейся в структуре. Указатели на объекты не содержат скопления переменных, а идентифицируют их. Если у кого есть указатель, который идентифицирует структуру, оператор -> может использоваться для доступа к переменной, хранящейся в структуре, идентифицируемой указателем.

В С++ структуры и классы не только объединяют переменные, но также могут прикрепить к ним код. Использование . для вызова метода будет в переменной запрашивать, чтобы этот метод воздействовал на содержимое самой переменной; используя -> для переменной, которая идентифицирует объект, попросит этот метод воздействовать на объект, идентифицированный переменной.

В Java все пользовательские типы переменных просто идентифицируют объекты, а вызов метода для переменной укажет методу, какой объект идентифицируется переменной. Переменные не могут содержать какой-либо составной тип данных напрямую, а также нет способов, с помощью которых метод может получить доступ к переменной, с которой она вызывается. Эти ограничения, хотя и семантически ограничивают, значительно упрощают время выполнения и облегчают проверку байт-кода; такие упрощения привели к сокращению ресурсных издержек Java в то время, когда рынок был чувствителен к таким проблемам и, таким образом, помог ему получить прибыль на рынке. Они также означали, что нет необходимости использовать токен, эквивалентный ., используемому на C или С++. Хотя Java могла бы использовать -> так же, как C и С++, создатели решили использовать односимвольный ., поскольку он не нужен для каких-либо других целей.

В языках С# и других языках .NET переменные могут либо идентифицировать объекты, либо хранить составные типы данных напрямую. Когда используется переменная составного типа данных, . действует на содержимое переменной; при использовании для переменной ссылочного типа . действует на объект, идентифицированный им. Для некоторых видов операций семантическое различие не имеет особого значения, но для других оно есть. Наиболее проблематичными являются ситуации, когда метод составного типа данных, который будет изменять переменную, на которую он вызывается, вызывается в переменной только для чтения. Если делается попытка вызвать метод для значения или переменной только для чтения, компиляторы обычно копируют переменную, позволяя этому методу действовать и отбрасывают переменную. Это в целом безопасно с методами, которые только читают переменную, но не безопасны с методами, которые пишут на нее. К сожалению, до сих пор не существует каких-либо средств для указания того, какие методы можно безопасно использовать с такой заменой и которые не могут.

В Swift методы агрегирования могут прямо указывать, будут ли они изменять переменную, по которой они вызывают, и компилятор запретит использование методов mutating для переменных только для чтения (вместо того, чтобы их мутировать временные копии переменной который затем будет отброшен). Из-за этого различия использование токена . для вызова методов, которые изменяют переменные, на которые они вызывается, намного безопаснее в Swift, чем в .NET. К сожалению, тот факт, что тот же токен . используется для этой цели, чтобы воздействовать на внешний объект, идентифицированный переменной, означает возможность путаницы.

Если бы у вас была машина времени и вернулась к созданию С# и/или Swift, можно было бы ретроактивно избежать большей части путаницы, связанной с такими проблемами, поскольку языки использовали токены . и -> намного ближе для использования на С++. Методы как агрегатов, так и ссылочных типов могут использовать . для воздействия на переменную, на которую они были вызваны, и -> воздействовать на значение (для композитов) или предмет, идентифицированный им (для ссылочных типов). Однако этот язык не разработан таким образом.

В С# нормальная практика для метода изменения переменной, с которой она вызывается, заключается в передаче переменной в качестве параметра ref методу. Таким образом, вызов Array.Resize(ref someArray, 23);, когда someArray идентифицирует массив из 20 элементов, вызовет someArray для идентификации нового массива из 23 элементов без влияния на исходный массив. Использование ref дает понять, что следует ожидать, что метод изменит переменную, на которую он вызывается. Во многих случаях выгодно изменять переменные без использования статических методов; Быстрые адреса, что означает использование синтаксиса .. Недостатком является то, что он теряет разъяснения относительно того, какие методы воздействуют на переменные и какие методы воздействуют на значения.

Для меня это имеет смысл, если вы сначала замените свои константы на переменные:

a[i] = 42            // (1)
e[i..j] = [4, 5]     // (2)

Первая строка никогда не нуждается в изменении размера a. В частности, ему никогда не нужно выделять память. Независимо от значения i, это легкая операция. Если вы представляете, что под капотом a есть указатель, он может быть постоянным указателем.

Вторая строка может быть намного сложнее. В зависимости от значений i и j вам может потребоваться управление памятью. Если вы представляете, что e - это указатель, указывающий на содержимое массива, вы уже не можете считать, что он является постоянным указателем; вам может потребоваться выделить новый блок памяти, скопировать данные из старого блока памяти в новый блок памяти и изменить указатель.

Кажется, что разработчики языка пытались сохранить (1) как можно более легким. Поскольку (2) может потребовать копирования в любом случае, они прибегают к решению, что оно всегда действует так, как будто вы сделали копию.

Это сложно, но я рад, что они не сделали его еще более сложным, например. специальные случаи, такие как "если в (2) я и j - константы времени компиляции, и компилятор может сделать вывод о том, что размер e не изменится, тогда мы не скопируем".

Наконец, основываясь на моем понимании принципов дизайна языка Swift, я считаю, что общие правила таковы:

• Использовать константы (let) всегда везде по умолчанию, и серьезных сюрпризов не будет.
• Используйте переменные (var) только в том случае, если это абсолютно необходимо, и будьте осторожны в этих случаях, так как будут сюрпризы [здесь: странные неявные копии массивов в некоторых, но не во всех ситуациях].

Что я нашел: массив будет измененной копией указанной , если и только если операция может изменить длину массива. В последнем примере f[0..2] индексирование со многими, операция может изменить свою длину (возможно, дубликаты не разрешены), поэтому она копируется.

var e = [1, 2, 3]
var f = e
e[0..2] = [4, 5]
e // 4,5,3
f // 1,2,3


var e1 = [1, 2, 3]
var f1 = e1

e1[0] = 4
e1[1] = 5

e1 //  - 4,5,3
f1 // - 4,5,3

Многие ранние последователи Swift жаловались на эту семантику, подверженную ошибкам, и Крис Латтнер написал, что семантика массива была пересмотрена, чтобы обеспечить полную семантику значений (Ссылка для разработчиков Apple для тех, у кого есть учетная запись). Нам придется подождать, по крайней мере, для следующей беты, чтобы понять, что именно это означает.

Строки и массивы Delphi имели ту же самую "особенность". Когда вы посмотрели на реализацию, это имело смысл.

Каждая переменная является указателем на динамическую память. Эта память содержит счетчик ссылок, за которым следуют данные в массиве. Таким образом, вы можете легко изменить значение в массиве без копирования всего массива или изменения любых указателей. Если вы хотите изменить размер массива, вам нужно выделить больше памяти. В этом случае текущая переменная укажет на вновь выделенную память. Но вы не можете легко отследить все другие переменные, указывающие на исходный массив, поэтому вы оставите их в покое.

Конечно, было бы непросто сделать более последовательную реализацию. Если вы хотите, чтобы все переменные отображали размер, сделайте следующее: Каждая переменная является указателем на контейнер, хранящийся в динамической памяти. Контейнер содержит ровно две вещи: счетчик ссылок и указатель на фактические данные массива. Данные массива хранятся в отдельном блоке динамической памяти. Теперь есть только один указатель на данные массива, поэтому вы можете легко изменить его размер, и все переменные увидят это изменение.

Для этого я использую .copy().

    var a = [1, 2, 3]
    var b = a.copy()
     a[1] = 42