Возможно, есть и другие примеры аналогичного поведения языков, как у C#, но это не в области моей компетенции. Если Вы таковые знайте, то было бы интересно на них взглянуть.
Хотелось бы конкретный пример кодом, доказывающим, что введение ограничение предлагаемого в Issue может сделать код неэффективным. На любом языке, на котором Вам удобно.
Я так с ходу не могу дать пример, но уверен - как только это запретят, сразу появится куча вопросов и примеров 
Так было с sealed abstract в своё время.
Вангую: имелось в виду, что у гипотетического программиста в его конкретной программе не сразу может появиться необходимость в реализации более широкого ограничения в его шаблонной подпрограмме, но при этом уже может быть четкое понимание, что это придется сделать в последующем.
Т.е. шаблонность им закладывается еще на этапе проектирования/прототипирования, но реализация этого шаблона происходит не сразу, а постепенно (напр., начиная с простейшего или наиболее часто используемого в алгоритме размерного типа), что не позволяет ему заранее точно описать такое ограничение через интерфейс или класс, но явно указывает самому себе на необходимость уточнения этого тип-а/ов в будущем.
Это аналогично модели разработки “снизу-вверх”: сначала создается минимальный костяк (корректно компилируемый), который затем постепенно функционально расширяется.
Все гораздо проще. Чтобы пересчитать количество разработчиков, пальцев даже на одной руке много. И они занимаются проектом, как уже подчеркивалось неоднократно, в свободное от работы время, коего у них весьма мало. Плюс, изначально не ставилась задача “догоним и перегоним С++, С# и Python в одном флаконе, взяв Паскаль за основу”. Язык уже огромен. Продолжать его расширять - это рисковать потерять контроль над проектом в целом, когда уже забываешь, зачем сделано то или это. Проекту скоро десять лет, а версии, которую можно описать так, чтобы там было всё-все, до сих пор нет. И не будет, если постоянно заморачиваться тем, чтО еще “кому-нибудь когда-нибудь может быть где-то” понадобится.
Идеями можно фонтанировать бесконечно, особенно когда их должны реализовывать другие.
С ними было много вопросов изначально, к примеру «abstract interface» (рассматриваю сейчас эти два модификатора раздельно). Запретили, на один вопрос стало меньше. Подумайте, все - же, над примером кода. Хотя бы, чтобы доказать свою точку зрения. Впрочем, Вы сами знайте, что код обладает великой силой - доказывать сказанное.
В отношении sealed abstract классов хочу заметить, что запрет был вполне обоснован: такая запись не очень говорящая, одна из первых ассоциаций, приходящих при взгляде на эти модификаторы класса - класс и запечатан и абстрактен одновременно. Но, если следовать это логике, то возникает противоречие: наследоваться от запечатанного класса невозможно, а значит (так как класс абстрактен) никто не может реализовать его функционал. Даже если это означает совсем другое, нежели выше приведенная одна из возможных интерпретаций, то это выглядит по меньшей мере странно, так как не вызывает требуемые ассоциации (что sealed abstract - статический класс) у программиста. В качестве примера кода (как не надо делать):
namespace Test
{
public abstract sealed class T
{
}
class Program
{
public static void Main(string[] args)
{
}
}
}
, который выдаст ошибку компиляции:
“Test.T”: абстрактный класс не может иметь тип sealed или static (CS0418) - C:\Users\Admin\Documents\SharpDevelop Projects\Test1\Test1\Program.cs:13,31
Код на VisualBasic.Net:
Module Program
MustInherit NotInheritable Class T // MustInherit == abstract, NotInheritable == sealed
End Class
Sub Main()
End Sub
End Module
также выдаст ошибку компиляции:
“MustInherit” и “NotInheritable” не могут использоваться вместе. (BC31408) - C:\Users\Admin\Documents\SharpDevelop Projects\VisualBasicTest\VisualBasicTest\Program.vb:10,2
Ссылки: MustInherit и NotInheritable.
Согласен с мнением @ibond.
Вы, разумеется, правы в том, что разработка проекта таким малым составом разработчиков - большая для них нагрузка. Но, все - же, не стоит забывать, что мнение и желание пользователей по улучшению среды и компилятора - важная вещь. Одно дело, если пользователь ничего не помогает искать из ошибок, а только предлагает улучшения, другое - когда он занимается и тем и другим. Те кто активно тестирует проект среди нас придерживается второй позиции. Конечно, хотелось бы больше тестировщиков, но, все - же, можно довольствоваться тем, что есть. Возможно, у Вас есть предложения по поводу привлечения тестировщиков в проект PascalABC.Net. Если да, то хотелось бы их услышать.
Язык нельзя описать хотя бы потому, что у него нет стандарта на данный момент.
На счёт рисков хочется сказать, что они есть всегда, особенно в разработке больших проектов.
Стоит заметить, что тема поднятого Вами вопроса с темой обсуждения про ограничения не коррелирует. Поэтому не может являться аргументом в контексте данной темы. Так, по поводу любого предложения можно упоминать эту проблему…
Вполне реальная ситуация.
Вы правы, по поводу любого внесения изменений в существующий проект, не являющихся ошибкой. Пока я по-прежнему вижу, что наиболее частый аргумент не конкретная нужда, а “посмотрите, вот так сделано в C#”.
Лично я кроме ссылки на C# часто говорю почему именно я считаю, что так сделать будет лучше. Да, C# тут часто упоминается. Но, ничего нет плохого в этом. Никто не был бы против также часто слышать и про Фортран здесь (Вы точно не были бы против 
). Или про любой другой язык.
Я категорически против тащить сюда что-то из Фортрана. Разве только общий принцип тех же многомерных срезов, но их уже и так утащили в Питон, на который разработчики тоже делают оглядку. А так - за меня уже все сказал классик:
В одну телегу впречь не можно
Коня - и трепетную ланьМного куда делается оглядка при разработке PascalABC.Net. Кстати, Issue про срезы матриц все также висит… Может, поднять эту тему здесь на форуме? Я уже там отразил своё мнение, пора бы услышать мнение и других.
Но есть иерархия. Прежде всего - Дельфи, FPC (они тоже Паскаль). Потом уже все остальное.
Да. Мне разработчики объяснили проблемы, которые возникают в связи с этим. Поэтому я не считаю для себе приемлемым снова раскачивать этот больной зуб. Помимо форума, у меня есть дополнительный, менее формальный канал канал общения, поэтому я временами выступаю с заявлениями, которые могут быть схожи с позицией разработчиков, хоть и не озвучивались тут.
Хорошо, не буду поднимать эту тему. Если кто-то все-таки решится, пусть это сделает (если захочет).
Можно с этого места поподробнее?
Нельзя. Если бы разработчики хотели что-то публично озвучить, они бы это сделали.
В таком случае побеседую через личные сообщения с разработчиками. Разумеется, выносить на общее обозрение сказанное ими я не буду.
Это правильное решение.Если посмотрите, я даже issure не пишу, хотя ошибки тоже иногда выявляю. Особенно, когда на самом деле они не являются ошибками. Часто проще сначала обсудить в личной беседе, чем писать пр принципу “А не понравится - удалят”…Но, повторюсь, это лишь мое личное мнение, я никому его не навязываю в качестве мерила поведения.
Хотел бы только заметить, что при прочих равных, ссылка на “так УЖЕ где-то работает и это очень удобно/эффективно” гораздо более весомый аргумент в защиту своего предложения расширять удобство и функционал языка, чем ссылка на “посмотрите, так НЕ работает/ НЕ принято там-то или там-то” в защиту своей идеи с целью ограничивать уже работающий функционал.
В данном случае мы имеем дело как раз со вторым вариантом. Более того, речь идет об удалении мелкой особенности, которая работает и никому не создает проблем. Не понимаю, к чему тут вообще ломать копья, неужели нету более продуктивных задач?
Если что-то работает, и работает правильно, смысл удалять? Но только работает не где-то, а в конкретной реализации, о которой речь. Если это PascalABC.NЕТ и в нем что-то уже работает, так это никто и не удаляет от нечего делать. А если это работает в каком-то другом языке, то пусть там и работает дальше.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021