Статические массивы реализованы через динамические. Это рудимент старого Паскаля, они не рекомендованы к использованию и дорабатываться никак не будут.
Точно так же и указатели - они сделаны лишь для совместимости со старым Паскалем и дорабатываться не будут.
Под индексатором this я подразумевал главное индексное свойство массива, реализованное на C# в самой .NET в сборке System.dll. Понятное дело, что конструкция не работает в паскале в таком виде.
Ну я это и имел ввиду. Хорошо бы это исправить.
Я сказал про них только для того , чтобы их не забыли. Хотя, Вы правы.
Почему? Они ведь позволяют оптимизировать приложение! Взять те же массивы!
В этом есть хоть какой то смысл:
Begin
Var Variable: Byte;
Var P := (^Byte)(@Variable);
End.
Но вряд ли ^Byte(@Variable), как и обращение к шаблонному типу не заполняя шаблон - слишком нагружает язык.
Паскаль в принципе не очень хорош со стороны оптимизации, он хорош для написания сложного по простому.
Под .NET используется в первую очередь управляемая память. Указатели относятся к неуправляемой памяти, и их использовние замедляет .NET-приложение
Если постараться, то хорош и так и так. 
Тогда почему же с ними работает быстрее? Я сам это проверял, и убедился. Причём именно на Паскале, не C#.
Эта память не контролируется сборщиком мусора. Это плохо сказывается на производительности в большом
Да почему же неуправляемая? Указатель на элемент динамического массива ведь не делает его неуправляемым. То есть можно работать с динамическим массивом не по индексатору, а по указателям на элементы. Если не верите мне, посмотрите статью, из которой я сам об этом узнал: https://habr.com/post/196578/. Там рассказано о многократном ускорении работы с Bitmap как раз с использованием указателей.
Это да, но это именно сам указатель. 4 либо 8 байт.
Нет. Память, которую он контролирует. Она является неперемещаемой и не собирается сборщиком мусора
Да. Но на короткий срок. Такую память надо специально фиксировать чтобы сборщик мусора её не переместил. И это сказывается на производительности если Вы её не расфиксировали. Хотя в этот момент - да - обращение к Bitmap - быстрое. Но это - крайне редкая операция. Вот как раз для работы с Bitmap 
Вот видите! Но операция эта не такая уж и редкая. Например, если заниматься обработкой изображений… Хотя у меня, сколько работаю, ни разу не было никаких конфликтов со сборщиком, хотя я вызывал его регулярно после того, как массив оказывался ненужным и ему присваивался nil. Возможно, в теории, Вы и правы, но на практике всё получается иначе.
Я говорю об общем количестве issure и, кстати, пост был именно в связи с очередной “хотелкой”. Среди тех хотелок есть совершенно неравноценные по востребованности: одни - это вещи, нужные единицам, другие же могут “скрасить жизнь” тысячам. Но и те и другие - “хотелки”.
Это не работает:
program pr1;
[System.STAThreadAttribute]
begin
end.
Предлагаю разрешить писать код сверху. При чём атрибут должен применяться к обоим генерируемым Main, потому что STAThread игнорируется если стоит не в точке входа в программу, а, к примеру, MarshalAs сработает не так как ожидалось, если прикрепить его только к точке входа.
А что там скрасит жизнь тысячам?
Например, срезы матриц, без которых во многих задачах сейчас приходится городить огород из процедур. Или недавно предложенная распаковка кортежа в циклах foreach.
Вообще, кортеж получить просто, а добиться потом толку от него гораздо сложнее. Особенно, когда это последовательность или массив кортежей. Например, чтобы найти индекс минимального элемента в таком массиве, приходится писать что-то вроде
begin
var s:='Карл у Клары украл кораллы Клара у Карла украла кларнет';
var a:=s.ToWords.Select(t->(t,t.Length)).ToArray;
//a.Println;
var imax:=a.Select(t->t[1]).ToArray.IndexMax;
Writeln('Первое из самых длинных слов; ',a[imax][0])
end.
А предложите что то лучше
.Select(t->t[1]).ToArray.IndexMax лучше заменить на .MaxBy(t->t[1])[0]. И быстрее и короче. И в пользе от первого .ToArray я очень не уверен. Заменить бы хотя бы на .ToList - уже немного лучше будет. Правда, на столько лучше по производительности, сколько и по длине)). Но вроде его можно и полностью убрать, пока .Println закомментированно - будет работать не медленнее.
Хм… Забавно, о каких тысячах вы говорите?! Где они, ау-у-у! Давайте ради объективности проведем эксперимент – поставим здесь голосовалку и пересчитаем всех, кто добровольно использует этот паскаль в работе и жизни, хотя бы время от времени. Обычные школьники и студенты, вынужденные на нем учиться по программе, не в счет! Абсолютное большинство из них забудут про него, как только покинут свои альма-матер.
@admin Давайте попробуем посчитать только тех, кто реально интересуется сабжем. Самому стало интересно, каков же реальный размер комьюнити (т.е. хотя бы тех, кто иногда почитывает этот форум)? Предположу, что не более 40-50 чел. – я сегодня оптимист!
Это похоже. Так и система - для студентов и школьников преимущественно. В продакшне её позиционирование непонятно. Может использоваться для научных расчётов и чтобы быстро что-то попробовать.
Ну как это не в счёт. Для них и писалось. Их десятки тысяч.
Давайте вот ещё Вас вычеркнем по какой-то причине и тоже скажем “не в счёт”
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021