При итерировании соответствия порядок в коллекции обратный, т.е. сначала идёт последний элемент коллекции
Ы=Новый Соответствие();
Для а=1 по 10 Цикл
  Ы.Вставить( а);
КонецЦикла;

Для Каждого КлючИЗначение Из Ы Цикл
  Сообщить(КлючИЗначение.Ключ);
КонецЦикла;
Если сделать тоже самое для структуры, то будет по мере добавления.

В 8.3.19 тоже получаю такой порядок.
В 8.3.12 и ниже, 8.2, 8.1, 8.0 - это неверно.
Порядок этот не гарантирован и может быть нестабильным даже в одной версии платформы.
Если важен порядок обхода, то нужно использовать таблицу значений. Тогда будет всегда и везде работать как заложишь.

Соответствие НИКОГДА не гарантирует порядка итерации.
Если тебе нужен именно порядок - используй более другие коллекции, например, список, массив или ТЗ.

(0) если в документации порядок не описан то на него нельзя закладываться, даже если он есть

Поменяли получается функцию хэша.
Ведь внутри соответствия все равно лежит массив

В Go эту проблему решили кардинально: итерация выдает элементы в случайном порядке. Это очень быстро отучило всех закладываться на порядок итерации.

Надо бы и 1С так сделать. Не в ущерб производительности, конечно.

P.S. Странно, почему об этом говорю я, а не наш Go евангелист. :)

(4) Это вряд ли...

(5) Оригинально

(4) Инфа 100%?

(5) Ну так и в 1С тоже в псевдослучайном порядке выдаёт :)

(5) Любая итерация? Расстрелять за это.

(0) для структуры этот код работать не будет

(7) Вафель херни не скажет, даже не смотря на то, что там лежит дерево)

(4) Внутри соответствия лежит std::unordered_map
Конечно, можно сказать что бакеты это массив - ну тогда в платформе внутри всего лежат массивы.
Ведь любой кусок памяти это массив...

(5) Это какой-то дебильный способ решения.
Нормальный, например - https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/LinkedHashMap.html
Порядок обхода соответствует порядку добавления.

(12) std::unordered_map в веб-клиенте? чем смотрел, что курил?

(11) какое дерево. это же хэш мап. хэш функция дает индекс массива

(14) Хеш мап несколько сложнее массива.

(12) Фиксированный порядок обхода это дополнительные накладные расходы. И невозоможность заменить реализацию на более оптимальную в будущем.

Для случаев, когда порядок обхода важен, есть другие коллекции.

А для чего для соответствия ключ-значение должен быть фиксированный порядок обхода? зачем?

Не понимаю - если есть обход, то почему его порядок случайный?

(18) э, это уже частности! давайте от общего к частностям.
обход - то бишь перебор - может быть и фиксированным и случайным. Почему для ключ-значение НУЖЕН фиксированный? практический смысл?

Не понимаю. Если перебор случайный, зачем вообще ключ-значение в СУБД?

Или точнее зачем нужен перебор, если есть ключ-значение.

Грубо говоря - если в системе ЭТОТ объект использует метод ДЛЯ КАЖДОГО, то каждый следующий в ОДНОМ обходе должен соответствовать каждому следующему в ДРУГОМ обходе. Почему нет?

В 1с не случайный, но не совпадает с порядком добавления.

(22) А почему да?

А - абстракция.

Бывают коллекции вообще без обхода.

Сорян, погорячилась.

Порядок в соответствиях зависит от фазы Луны, давно известный факт

(0) Скорее всего это происходит из-за того, что память выделяется постепенно. В каждом элементе коллекции есть ссылка на предыдущий элемент ( что бы уменьшить объём выделения памяти ) и так мы имеем:

Ы -> Ссылка на структуру последний элемент.

Последний элемент
   Ключ,
   Значение
   Ссылка на предпоследний

... Куски занятой памяти

Предпоследний элемент
   Ключ,
   Значение
   Ссылка на Предпоследний элемент - 1

...

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

(28) По идее должно быть так:

Структура это 2 массива

1-й массив это упорядоченный ключ
2-й массив ( условно ) это хранящиеся значения. Что бы в случае замещения значения с имеющимся ключём освободить память значения, выделить новый кусок памяти под новое значение ( плавающее по размеру ).

Элемент ключа

Ссылка на предыдущий элемент
Ссылка на Значение

Почему так:

Да по тому что вставляя элемент ищется куда его вставить для упорядочивания ключа

1. Выделяется свободный кусок памяти.
Далее ищется куда в цепочке засунуть новый элемент
Прописываются ссылка в зависимости от вставки
Ссылка разрываемого элемента корректируется

В те элемент, который разрывается корректируем ссылку:

Элемент 1
Элемент 3

Вставляем элемент 2 к примеру:

Так как Элемент 3 ссылается на Элемент 1 и нужно это подправить ( данные в памяти разумеется никто не передвигает ):

Элемент 1 <------+
                 |
Элемент 3------+ |
               | |
+-- Элемент 2<-+ |
+----------------+

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

(27) Скорее всего из ходя из домыслов в (29). Соответствие тупо выбирается из упорядоченного массива

(21) вот именно, это и интересно.

(0) а никто и не обещал

Вот например: https://infostart.ru/public/117041/

Вероятно, обсуждается работа с ключ-значение внутри запросов и всякие соединения с данными и временными таблицами?

ХэшФункция никогда не дает однозначности
Будет массив хэшей и массив массивов значений хэшей.
Что касается самих значений,то размер переменной в любом языке фиксирован,что не влезло (строки,объекты и т.п.) хранятся в отдельной памяти.

Опять же,реализация через одно или двухсвязные списки - это самое простое,но в реальности,проще работать с блоками памяти,причем или фиксированного размера или нескольких фиксированных размеров,тогда фрагментация памяти меньше влияет на производительность.

Сделать перебор в случайном порядке - сложно,а вот начать перебор с текущего элемента можно.

И порядок элементов позволяет в процессе перебора добавлять элементы в коллекцию,зная,что они будут в конце. Если этого нет,то добавление элемента в процессе перебора будет приводить к странным последствиям.

(35) но ведь 1с не обещала порядок перебора? Значит на это рассчитывать нельзя

(35) Изменение перебираемой коллекции в общем случае - UB. А за такое по рукам линейкой шлёпают.

Помнится в ТП 5.5 успешно пользовался кучей и указателями. Можно было такие фишки выделывать, такую настраиваемость универсальность создавать при решении задач а главное всем управляешь сам - вплоть до оверлеев и до ассемблерных вставок. Это была Жизнь :)

(38)+ Хотя в 1с все это же присутствует в т.ч. в виде внешних компонент.

(38) В ТП5 оверлеии и ассемблер были искаропки.

(38) а в Фортране можно было оверлеи делать на области данных...

(38) Жизнь была на Ассемблере только, остальное все - извращения нетолерантные... ;-)

(1) а для массивов при переборе элементов в цикле Для каждого порядок тоже может отличаться от цикла Для i=0 и получения элементов через А[i]?

(43) Массив гарантирует последовательность.

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

(0) А где-то обещали порядок? "Для каждого" озачает, что каждый элемент будет извлечен внутрь операторных скобок цикла, но что это будет в определенном порядке - где это обещали? Покажите мне это место в доке.

А повторно уже ранее полученный элемент может быть?

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

(0) А что не так?
Хотите упорядочивание - используйте конструкции, где есть упорядочивание.

а так это как в "выбрать первые 1 из ...." без упорядочивания, вот всегда возвращалась правильная ссылка, а теперь неправильная!!!! ПЛОХАЯ 1С НЕГОДНАЯ