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

Условно, если нужно только length и get_index, то вполне можно этим и ограничиться и не думать о том, что полная версия массива должна быть намного больше/сложнее. Разумеется всё задачей определяется.

У меня в своё время это было, когда я со строками работал. Закончилось просто тем, что я сделал тип что-то вроде

struct MyString <: AbstractString
  data::String
  l::Int
end

Base.::length(x::MyString) = x.l

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

Разумеется, это была внутренняя структура и наружу не экспортировалась, во избежание недоразумений.

Там проблема в том, что copyto! копирует наследников AbstractArray поэлементно идя по индексу и не используя итератор, даже если он определен.
Как-то вот так:

@inbounds for i in srcinds
        dest[i] = src[i]
    end

И даже если ты определил полный интерфейс для своего массива, но у тебя медленный случайный доступ (например ты данные с диска последовательно поднимаешь) то не смотря на полный интерфейс массива идея формально указать что ты наследник AbstractArray так себе....

А почему нельзя переопределить copyto для своего типа массива, чтобы он уважал итератор?

Можно. Но я не уверен, что нужно переопределить только copyto! В принципе если бы в документацию вынесли все методы, которые нужны для нормального фунционирования AbstractArray вне зависимости от его внутренней архитектуры (он может быть например list по реализации), то уже это решило бы проблему. А так нужно методом тыка искать где еще в ядре решили что итератор использовать необязательно

Есть еще куча методов для AbstractVector, которые тупо не добавили в StructArray

Да это может и не проблема, но опять таки если у них есть реализация по умолчанию и она работает ожидаемым образом.

Хм, я тут подумал, а как в принципе должна copyto работать с итераторами? С правой частью всё понятно, а вот что делать с левой?

То есть либо в какой-нибудь enumerate оборачивать и тогда копия будет в потенциально другом порядке писаться, либо итератор должен возвращать значение и индекс.

Но это явно очень узкий класс массив, который будет уметь так делать.

В Julia это стандартно внешним пакетом решается, в Base такого точно не будет.

Вот ведь... А ведь правда.  Как-то так незаметно договорились до того что вообще итераторы в Джулии странно устроены. 🙂 Видимо дейсвительно нужно для кастомных массивов переопределять copyto!

В stl в плюсах итераторы хорошо устроены. В плане позволяют отделить алгоритмы от внутреннего устройства массивов.

А как это бы выглядело в рамках текущей задачи?

В смысле как бы в плюсах выглядело?

Эх....
Я уже забыл как плюсы выглядят 😊

Как бы оно выглядело в Джулии, если бы в ней итераторы были как в stl в плюсах.

Я понимаю, что задачка так себе 😊)) Но если это возможно написать, то было бы интересно посмотреть. На условном псевдокоде.

Ну что-нибудь типа такого

for a in src
     set!(dest_it, a)
     next!(dest_it)
end

Ну т.е. предполагается что итератор хранит состояние и указатель на текущий элемент. На плюсах это выглядит примерно так

for(auto src_it = src.begin(); src_it < src.end(); ++src_it) {
*dest_it = *src_it;
++dest_it;
}