Ещё вопрос по F#. В реальных проектах принято указывать возвращаемые и

принимаемые типы функцией или всё «по-наследству»?)

Вывод типов по Хиндли-Милнеру дает возможность не обмазывать код простынками из деклараций типов, это та одна из уберфич ML семейства языков, почему я обожаю пилить код на фарше

Не пали тему) пусть сишарперы страдают)))

А как ревьюить такой код без ИДЕшки? Ведь вообще не понятно с чем оно работает.

Не

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

Дык статический вывод типов, компилятор рога отшибет при ошибке. А типы реально не нужны в декларациях-нужно сосредоточиться на том, ЧТО происходит, а не поверх чего :)

я паблик апи таки обмазываю чтобы не заинфирилось ненужное

При подходе-функции работы с типом расположены ТОЛЬКО в том же модуле, что и сам тип-сильно уменьшает вероятность упороться. Сам тип в таком случае может только гулять по стеку вызовов и все :))

Функции без классов?

Я почти всегда леплю на рекордах+функциях вокруг них в том же модуле. За исключением публичных АПИ своего движка-там интерфейсы торчат :) Т.к. когда нибудь может он станет публичным и не хочу шокировать публику F# way API 😂

А что вы создаёте, если не секрет?

Поищи по ECS, воксель-были посты

если твой код непонятен без аннотаций типов, то это в большинстве случаев плохой код

В точку. И даже необходимость втыкать явно inref/byref говорит о том, что код плохой, но иначе никак(ибо перформанс)

Хватит блин вручную код для компилятора писать:) Определи базовые операции которые ты со своей ecs ’кой выполняешь, попытайся привести к общему типу дженерик делегата который позволяет описать такие взаимодействия, определи несколько комбинаторов которыми их можно чейнить/объединять, а более хайлевел части уже этой dsl описывай:) по всем моими прикидкам ты должен уже давненько не иметь дела с байрефами лично:)

Inref/byref?!!! 🤦 у нас например обычная payment система, ну там транзакции денежные и т.д. Среднее время одной транзакции 60ms.

ХМ не выводит byref из контекста использования. Компилятор будет пинать тебя за то, что ты пытаешься его нагреть. Максимум он в override может за тебя сориентироваться, и то на некоторых хитрых ошибках он снова начинает тупить.

А где-то есть открытый источник, из которого ты эту идею взял?

Так это в потрохах ядра ECS всякая перформансная дичь творится, на внешней стороне API все благообразно(типа семпл): [<Sealed>] type private Iterate(_isParallel: bool, _world: IWorld, _settings: IEcsSettings) = interface ISystem<Component1, Component2, Component3> with member this.Description = "Sample three components" member this.IsParallel = _isParallel member this.IsOn = true member this.Filter = Filter.empty() [<MethodImpl(MethodImplOptions.AggressiveInlining)>] member this.Do(_, c1, c2, c3) = c1.Value1 <- c1.Value1 + c2.Value2 + c3.Value3

Я с обычными "системами" много лет предпочитаю не встречаться, мне надо превзмогание в разработке, так интереснее 😂

Верно, в декларациях никак не провихлять для inref/byref-приходится явно писать, чтобы ХМ рога не отшибал