Implicit function arguments в Rust

Там свои заморочки есть. Все операции в обёрнутую монаду XXX нужно прокидывать с помощью liftXXX, а если требуется работать с функциями, использующими разные монады — всё ещё веселее.

В чем смысл давать ссылку на комментарий в ответ на который я и написал свое сообщение?

Не заметил.

Отсутствие implicit arguments — это какой из этих вариантов?

Ну их много где нет, так что «проблема» не специфична для раста.

Особенно если какое-то значение понадобится в функции, которая вызывается не напрямую из main, а где-то на втором-третьем уровне

Вообще-то это и есть так называемые побочные эффекты, от которых в Haskell, что ты приводишь в пример, вообще принято избавляться. Передавай параметры явно.

Состояние мира не меняется, откуда там побочные эффекты? Неявность есть, побочных эффектов нет.

в Haskell можно замутить и глобальную переменную при желании, только надо не забыть одну прагму обозначить. Создатели Rust, очевидно, многое переняли из Haskell, и даже само название unsafe как-бы намекает

А я в Java EE могу через DI конфиг пошарить. Делает ли это функцию с ReaderT нечистой? Мне кажется, что нет. Потому что ни к одному, ни к другому он не относится.

Расшифруй. И кстати, unsafePerformIO может быть и чистым, но не ссылочно-прозрачным

Я не хаскеллист, я не знаю что такое unsafePerformIO. Про ReaderT в треде несколько раз подчеркивали, что он предоставляет в функцию константный стейт. Следовательно, он не может быть источником побочных эффектов. В этом был смысл поста, на который вы ответили приведя в пример возможность создания глобальной переменной. Какое отношение имеет глобальная переменная к ReaderT? Или я что-то не так понял?

Вообще-то это и есть так называемые побочные эффекты,

Нет.

Не понял вопрос. А как ещё можно обращаться к переменной?

Я криво сформулировал. Что будет, если локально объявить переменную с таким же именем?

Ну то есть ты тоже предлагаешь копии конфига повсюду рассовывать.

В расте не изобрели ещё di контейнеры?

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

TLS это считай глобальная переменная.

Зависит от того, куда этот TLS сунут. Но вообще ты прав, да.

Изначально речь была о чтении конфига. Вот и можно его прочитать, а потом сохранить результат в глобальной переменной, которые в Haskell, оказывается, тоже есть. Только это совершенно неидиоматический подход. Хотя мне кажется, что в некоторых случаях его используют, где вынуждены приспосабливаться к особенностям внешнего окружения, как то, какие-нибудь либы к GUI

Вообще так делать неправильно, но я бы колхозил так: Стек с конфигами thread local. Функция получения значений из конфига на вершине стека. Две функции для изменения конфига, одна принимает конфиг, добавляет в стек и возвращает некий объект, который при дропе удалит свой конфиг из стека, вторая - надстройка над первой, принимает конфиг и FnOnce, вызывает первую, вызывает функцию и потом дропает объект.

Потому как результат функции зависит не только от входных значений функции но и еще чего-то там во внешнем мире.

Это что-то является аргументом функции, передаваемым неявно. Побочный эффект то где?

Если так то ок. Я думал, что тут неизвестно когда начинает читаться файл конфига.

Я думал, что тут неизвестно когда начинает читаться файл конфига.

По факту так и есть, и неизвестно, когда закончится чтение.

Тогда это ни разу не круто

Добро пожаловать в реальный, многопоточный мир.

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

В другом потоке будет свой стек, а захотеть почитать ReaderT он может раньше, чем конфиг прочитается из файла.

Как можно использовать стейт до его инициализации? Можете код показать?

В другом потоке будет свой стек, а захотеть почитать ReaderT он может раньше, чем конфиг прочитается из файла.

Чувак, ты хрень написал. Перестань это делать.

Ммм, я правильно понимаю, что твою хотелку сейчас можно реализовать с помощью ассоциированных констант и (опционально) lazy_static?

struct ReaderT;

impl ReaderT {
    const X: i32 = 1;
    const Y: &'static str = "";
}

fn main() {
    println!("{}, {}", ReaderT::X, ReaderT::Y);
}

Хотя, с другой стороны, и раньше можно было делать:

mod config {
    pub const PARAM1: i32 = 1;
    pub const PARAM2: &str = "";
}

Нет, потому что мне не константы нужны. Если бы можно было impl делать локально и он бы передавался вниз по стеку вызовов, тогда да.