Несколько мыслей.
Во-первых, по умолчанию функции не реализованы. Чтобы реализовать функцию, кто-то должен подумать о ней. Затем мы должны спроектировать его, уточнить, реализовать, протестировать, задокументировать, найти для него транспортное средство и доставить его за дверь. Если что-то из этого не происходит, вы не получите эту функцию. Насколько я знаю, ничего из этого не произошло для этой функции.
Во-вторых, приоритетам функций являются их чистые выгоды, то есть их общая выгода для наших клиентов за вычетом наших общих затрат на их реализацию. Здесь есть очень реальные «альтернативные издержки». Каждая функция, которую мы ДЕЛАЕМ, - это десятки функций, на которые у нас нет бюджета. Поэтому функции не только должны стоить работы, чтобы их реализовать, они должны быть БОЛЬШЕ выгоднее, чем любая из тысяч функций, которые мы получили в наших списках запросов функций. Это высокая планка для достижения; большинство функций никогда не достигают этого.
Чтобы объяснить мой третий пункт, вам нужно немного узнать о том, как обрабатываются языки. Мы начинаем с того, что берем исходный код и «лексируем» его в «токены» - слова. На данный момент мы знаем, является ли каждый символ частью числа, строки, ключевого слова, идентификатора, комментария, директивы препроцессора и так далее. Лексинг невероятно быстр 1008 *; мы можем легко переделать файл между нажатиями клавиш.
Затем мы берем серии токенов и «разбираем» их в «абстрактном синтаксическом дереве». Это определяет, какие части кода являются классами, выражениями, объявлениями локальных переменных, именами, присваиваниями, чем угодно. Разбор также быстрый, но не такой быстрый, как lexing. Мы делаем некоторые трюки, например, пропускаем синтаксический анализ тел методов, пока кто-то на самом деле не смотрит на них.
Наконец, мы берем абстрактное синтаксическое дерево и делаем его семантический анализ; это определяет, относится ли данное имя к типу, локальной переменной, пространству имен, группе методов, полю и т. д. Мы выполняем как семантический анализ «верхнего уровня», чтобы определить иерархию типов программы, так и семантический анализ «уровня метода», чтобы определить тип каждого выражения в каждом методе. Семантический анализ «верхнего уровня» довольно быстрый, и любой отдельный метод анализа довольно быстр, но все же сложно провести полный семантический анализ между нажатиями клавиш.
Очевидно, что нам нужно выполнить полный семантический анализ для intellisense, но мы можем уйти от выяснения того, какой метод вы вводите в данный момент, и только выполнить семантический анализ верхнего уровня и этого метода.
Но раскраска должна работать на весь файл; Вы не можете просто раскрасить метод, в котором сейчас находится курсор. Поэтому раскраска должна быть безумно быстрой, поэтому исторически мы раскрашивали в основном на основе лексической информации.
Иногда мы можем придумать что-то особенное, например "эта вещь, вероятно, тип?" чтобы придать ему другой цвет. Но для определения, когда данная сущность является, скажем, группой методов или, скажем, полем типа делегата, требуется довольно богатый уровень семантического анализа, уровень, который мы в настоящее время не выполняем при каждом нажатии клавиши.
Теперь есть вещи, которые мы можем сделать здесь. Мы могли бы быть умнее в понимании изменений в потоке токенов и выполнять только грамматический и семантический анализ в отредактированной части дерева. Сейчас мы проводим некоторые исследования в этой области, но это просто исследование; он может никогда не превратиться в продукт.