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

vsb> Я имею в виду, что в теории компилятор знает значение выражения `name` и мог бы его передавать как-нибудь. Кстати это позволило бы получить информацию про generic типы, если вдруг кому-то надо.
Это уже какая-то другая фича, непосредствевнно к сабжу не имеющая. Если такое и делать, то без привязки к сабжу.

vsb> vsb>>А теперь то же самое для случая, когда name == null.
vsb> ·>А, понял. А setObject разве не сработает с java.sql.Types.NULL?
vsb> В общем случае не сработает, драйверу нужен правильный тип. Если его не передавать, он его пытается извлечь из переданного значения, но для null так не получится. В конкретных драйверах для конкретных БД может и сработает. Зависит от БД и драйвера, но в общем случае тип нужен.
В смысле в общем случае надо обязательно делать rs.setNull(Types.VARCHAR2)? Тогда да, придётся как-то этот тип затаскивать со значением парама. А вообще ты на старую мозоль наступил — the billion dollar mistake.

vsb> Суть фичи ведь в том, чтобы писать код, который компактней и понятней. Так-то можно и вообще без неё обходиться, как сейчас обходимся. А авто-комплититься и рефакториться будет любой синтаксис, не думаю, что для IDE есть разница, поддерживать только синтаксис \(expr) или ещё и \(expr: String).
Разница в том, что expr — это универсальный java-expr. Его можно в переменную извлечь или в метод, например. Если же специально для сабжа вводить какой-то новый string-template-expr, то это будет костыль сбоку. Вон тут прислали ссылочку на шарповый аналог, так это по-моему хак на хаке. В *стандарте* самого языка прописаны всякие alignment/width и прочее. ИЧСХ твоё {name:VARCHAR2} туда никак не укладывается всё равно.
В сабже компилятор делает лишь тупое заворачивание в List.of и всё, остальное — STR/FMT/etc — библиотечный код.

vsb> Фича классная, тут я не спорю. Я на самом деле когда-то в котлине агитировал сделать такую фичу, но не прислушались. А тут — в жаве почти что мне хочется.
Мне пока тоже не нравится твоя идея со встроенным специальным синтаксисом для шаблонных выражений, да ещё и кастомизируемым.

vsb> ·>А кто по-твоему должен парсить магию "\{name:VARCHAR2}"?
vsb> Что-то парсит компилятор, то, что после ":" — в случае FMT передаётся как обычная строка, в случае SQL, конечно, хотелось бы какого-то дополнения от IDE, а не просто обычную строку (хотя и так подошло бы). Тут надо подумать, как сделать это так, чтобы оба варианта работали.
Именно. Т.е. твои кастомные шаблоны в IDE из коробки неясно как будут работать. "Обычная строка" — ну нафиг, наелись, у нас же всё-таки строго типизируемый ЯП. А расширения типа "\{DB.VARCHAR2(name)}" ты можешь клепать как самый обычный java-код.

vsb> ·>Так ведь у них разные предназначения. STR это замена "aa" + n + "bb", а FMT это форматтер со своим синтаксисом. print vs printf
vsb> А если мне надо и то и то? Сейчас это FMT"map[%s\(key)] = %08x\(value)". А могло бы быть STR"map[\(key)] = \(value:08x)".
Принципиальная разница в том, что "aa" + n + "bb" — это фича компилятора, часть JLS. А FMT — это просто библиотечная функция по мотивам сишного printf, часть java.text в JDK. И ты можешь сам клепать подобные MY_BETTER_FMT.