Здравствуйте, Sinclair, Вы писали:

S>·>В java я знаю, что такой код сконвертится в String.valueOf(colour), который внутри ещё делает null-check: String valueOf(Object obj) {return obj == null ? "null" : obj.toString(); }. Т.к. c# сдирали с явы, то скорее всего будет что-то очень похожее.
S>Не "скорее всего", а будет ровно то, что я написал. Это часть спецификации языка, и результат нетрудно проверить.
Да говорю, что это всё неважно, это же игрушечный пример.
Стоит поменять на чуть более красивое $"You chose {colour}" и магия исчезла.
Или как я уже упоминал List<Colour>. Что теперь, и списки уже нельзя будет использовать?!

S>·>Но даже если вдруг не так, то не так уж важно, суть в том, что вызов метода ToString находится в 3rd party code, соответственно InterceptsLocation ставить тупо некуда.
S>Нет, не находится. Там нет никакого 3rd party code. Порождается именно такое AST, прямо в том месте, где идёт вызов WriteLine.
Именно, что только в данном случае. В этом и беда.

S>·>Поэтому вся эта затея с магическим ToStringFast очень хрупкая и практически никак не контролируемая, только в бложик написать годится. Если кто-то захочет внедрить подобное в проекте — надо будет сильно стукнуть по башке.
S>Ничего никуда не стукнет. Потому, что эта штука — оптимизационная. Её задача — не в том, чтобы менять семантику 3rd-party code, а в том, чтобы оптимизировать свой код.
Слишком хрупкая оптимизация.

S>·>Это всё не поможет. Всё равно остаётся миллион возможностей когда call site окажется за пределами досягаемости компилятора. Недаром я немного другой пример привёл с Logger.Info вместо +, там уж точно метод будет дёргаться хз откуда; так же лесом пойдут все функции и либы форматирования и шаблонизации.
S>1. Логгеры в дотнете устроены не так, как вы пишете.
S>2. Опять-таки: если есть какой-то сторонний код, который собрался что-то там логировать, то при использовании этой техники он просто продолжит работать как работал.
А как?

S>·>Ну да, это и надо делать, это то что будет полезно и покрывать практически всё возможно необходимое. Делать подмены call site — толку как с козла молока, очень узкий специфичный сценарий, неясно какие проблемы решающий.
S>Вполне ясно, какие проблемы он решает. В частности, он позволяет в тех местах, где происходит рантайм-анализ всякого разного, включая Expression Trees, подставить компайл-тайм результат.
Ок... Т.е. дать возможность пользователям играться с оптимизацией самого сишарп кода, когда сам компилятор не справляется?.. Ну не знаю, уж очень мало возможностей развернуться, имхо.

S>Если у вас есть приложение, у которого подобные запросы составляют значительную долю вычислительного времени, то банальный импорт пакета и перекомпиляция дадут вам перформанс буст на ровном месте.
S>Чем плохо-то?
Это интереснее. Может даже взлететь.

Мой спор был про упомянутые тут юнит-тесты и АОП и уж тем более дебаг-отладка — для них это точно не взлетит. Слишком много ограничений.