Raw-строки никто так правильно и не сделал ни в одном языке. Здесь получается что это обычные escape-строки со спецсимволом «решетка» (а не обратный слэш или что там еще бывает).
В моем понимании настоящая raw-строка это строка, перед которой задается произвольная пользовательская терминальная последовательность, далее идет строка, которая может содержать что угодно, пока не попадется еще раз эта терминальная последовательность.
Интересно, возможна ли технология, в которую изначально будет заложено сопротивление цензуре и блокировкам интернета? Т.е. некая адресация, не привязывающая контент к каким-либо адресам вообще и исключающая возможность отследить адрес получателя. Т.е. сделать весь интернет без исключения i2p-подобным, или как-то так.
На картинке только часть кода, непосредственно относящаяся к корутинам. Переменные a_promise и final_result глобальные, функция seq выводит строку на экран, в отличие от оригинального примера, где она заполняет массив буквами, соответствующими точками вызова.
Как я понимаю современные тенденции, удобнее парсить когда в начале известное, а за ним новое имя. В c++ на это напоролись и пришлось вводить typename перед именами типов в некоторых случаях в шаблонах. Во всех языках последнего поколения пишут обычно
var x: type = value
Здесь var/let/const — всегда известное ключевое слово, дальше имя, а тип опционален ибо в тренде автоматический вывод типов.
Неплохо. Я сейчас тоже готовлю статью по Zig. Язык действительно интересный и своеобразный, производит впечатление некой альтернативы Си, с более строгими правилами, оригинальной реализацией обработки ошибок (что-то вроде исключений, но другое), сопрограммами и встроенным метапрограммированием непосредственно на самом языке (блоки comptime позволяют писать код на Zig который будет исполняться прямо во время компиляции). Кстати, то что начинается с собачек («builtin functions») это не только встроенные функции, но и встроенные синтаксические макросы, предоставляющие доступ к компилятору. Т.е. под одним названием собрано и то и другое.
Просто брать и ломать совместимость. Перекомпилировать программу и заменить те слова, которые стали ключевыми, на что-то другое это в общем делается максимум в пределах рабочего дня, а в современном мире с интернетом распространить измененный код любых библиотек можно очень быстро.
Не факт. Например, если я объявляю массив на 1000 таких структур в драгой структуре, у меня внезапно тратится килобайт памяти, хотя структуры пустые. Можно конечно спросить — зачем делать массив из пустых структур, но такое может получиться случайно при метапрограммировании.
Вообще ситуация интересная, нужно думать.
Указатель на метод это указатель на функцию, там проблем нет.
А если нужен указатель на объект без полей для передачи его в качестве «this», то он все равно не должен использоваться (полей-то нет) — поэтому компилятор может или выкинуть неявный аргумент this вовсе, или передавать null. Если же есть виртуальные методы, по появляется поле vfptr, значит уже не 0 байт.
Ну если размер объекта 0 байт, то объекта не существует в памяти, не так ли? И совершенно логично, что операции перемещения по байтам в памяти для такого объекта бессмысленны. Фактически, объекты и массивы типа void, если их ввести в некий язык программирования, могут существовать только на этапе компиляции, для каких-то целей обобщенного метапрограммирования. В скомпилированной программе никаких следов таких объектов оставаться не должно.
Компилятору известно что объект 0 байт, стало быть он может выдать ошибку при попытке получить адрес такого объекта (или возвратить NULL, не знаю как лучше), и т.д.
Чем ситуация с аугментацией будет отличаться от того что есть сейчас? Человек у которого есть автомобиль более прокачанный чем тот у кого нет? Автомобилисты считают пешеходов недолюдьми?
Или человек у которого есть смартфон более прокачанный чем тот у которого нет? И т.д.
Все это лишь инструменты, и по мере появления инструментов будут появляться и правила их использования.
Причина — инерционность человеческого мышления.
Ну и порог вхождения самого языка. Это же еще и библиотеки/фреймворки, и среды разработки, и отладчики.
Очень интересная тема! Огромное вам спасибо за нее, и комментарии очень интересные. У меня на хабре практически все статьи так или иначе не эту тему.
Почти со всеми хотелками согласен. Немножко прокомментирую. Синтаксическая чистота. Глядя на незнакомый код, программист должен четко понимать — где тут операторы, где ключевые слова, где идентификаторы и т.д. То есть в языке должны быть простые правила разделения всех возможных синтаксических сущностей на категории, и по виду сущности сразу должно быть понятно к какой категории она относится. Это же огромное облегчение для syntax highlighter'ов. Кортежи. Я в свое время написал аж две статьи здесь, на тему кортежей и своих хотелок с ними связанных. Да, кортежи должны однозначно быть частью языка, они должны лежать в основе синтаксиса языка а не прикручиваться снаружи как это зачастую бывает. По сути в любом языке «последовательность чего-то через запятую» — базовый кортеж, и от этого нужно строить весь синтаксис. tagged unions Штука полезная, поддержка со стороны компилятора должна быть, но хотелось бы, чтобы чистые перечисления и чистые (низкоуровневые) unions остались. константы — все верно. Вы очень точно сформулировали про виды констант. Call-by-name семантика Интересны вопросы реализации. Это может быть рантайм — неявно генерируемая лямбда-функция, или compile-time — тогда это шаблонная функция, принимающая фрагмент кода шаблонным параметром. преобразования да, идея с явным разрешением (или явным запретом) преобразований очень красивая. Для разных программистов и для разных целей может требоваться разный уровень «неявности» преобразований. рефлексия — может тоже опцией? хотим сгенерировать для класса метаинформацию — добавляем какое-то ключевое слово перед описанием класса, или ставим глобальную прагму. А кому-то может наоборот нужно оставить в бинарнике как можно меньше следов:) Значения, ссылки, указатели примитивные типы не должны притворяться, они должны быть объектами — но при этом оставаться примитивными типами! Не понимаю почему так не сделать. Ну и по шаблонам в С++ — это концепты, то есть по сути введение нормальной статической типизации в систему шаблонов. Все те гигантские error'ы, которые вылазят, если в шаблон передать не то что ожидается — прелести динамической типизации:) Минимум сущностей вот здесь не согласен. Поля, методы и свойства — это разные сущности, пускай и будут разными. Делать все поля приватными насильно — не хочу. Макросы однозначно да. Я писал об этом статью со своим видением, впрочем с тех пор уже кое-что поменялось, да и в дискуссии выяснились некоторые дополнительные факты — в частности, людям нужен универсальный код, который можно выполнить и в runtime и в compile-time. Функции внутри функций Ну это вообще очевидная вещь. В расширениях GCC она реализована давно, но в стандарте до сих пор нет. Почему? Substructural type system пока не очень понятно Сборка однозначно не так как в С++. Во всех следующих языках все сделано гораздо лучше.
В моем понимании настоящая raw-строка это строка, перед которой задается произвольная пользовательская терминальная последовательность, далее идет строка, которая может содержать что угодно, пока не попадется еще раз эта терминальная последовательность.
Здесь var/let/const — всегда известное ключевое слово, дальше имя, а тип опционален ибо в тренде автоматический вывод типов.
Вообще ситуация интересная, нужно думать.
А если нужен указатель на объект без полей для передачи его в качестве «this», то он все равно не должен использоваться (полей-то нет) — поэтому компилятор может или выкинуть неявный аргумент this вовсе, или передавать null. Если же есть виртуальные методы, по появляется поле vfptr, значит уже не 0 байт.
Компилятору известно что объект 0 байт, стало быть он может выдать ошибку при попытке получить адрес такого объекта (или возвратить NULL, не знаю как лучше), и т.д.
Или человек у которого есть смартфон более прокачанный чем тот у которого нет? И т.д.
Все это лишь инструменты, и по мере появления инструментов будут появляться и правила их использования.
Ну и порог вхождения самого языка. Это же еще и библиотеки/фреймворки, и среды разработки, и отладчики.
Почти со всеми хотелками согласен. Немножко прокомментирую.
Синтаксическая чистота. Глядя на незнакомый код, программист должен четко понимать — где тут операторы, где ключевые слова, где идентификаторы и т.д. То есть в языке должны быть простые правила разделения всех возможных синтаксических сущностей на категории, и по виду сущности сразу должно быть понятно к какой категории она относится. Это же огромное облегчение для syntax highlighter'ов.
Кортежи. Я в свое время написал аж две статьи здесь, на тему кортежей и своих хотелок с ними связанных. Да, кортежи должны однозначно быть частью языка, они должны лежать в основе синтаксиса языка а не прикручиваться снаружи как это зачастую бывает. По сути в любом языке «последовательность чего-то через запятую» — базовый кортеж, и от этого нужно строить весь синтаксис.
tagged unions Штука полезная, поддержка со стороны компилятора должна быть, но хотелось бы, чтобы чистые перечисления и чистые (низкоуровневые) unions остались.
константы — все верно. Вы очень точно сформулировали про виды констант.
Call-by-name семантика Интересны вопросы реализации. Это может быть рантайм — неявно генерируемая лямбда-функция, или compile-time — тогда это шаблонная функция, принимающая фрагмент кода шаблонным параметром.
преобразования да, идея с явным разрешением (или явным запретом) преобразований очень красивая. Для разных программистов и для разных целей может требоваться разный уровень «неявности» преобразований.
рефлексия — может тоже опцией? хотим сгенерировать для класса метаинформацию — добавляем какое-то ключевое слово перед описанием класса, или ставим глобальную прагму. А кому-то может наоборот нужно оставить в бинарнике как можно меньше следов:)
Значения, ссылки, указатели примитивные типы не должны притворяться, они должны быть объектами — но при этом оставаться примитивными типами! Не понимаю почему так не сделать. Ну и по шаблонам в С++ — это концепты, то есть по сути введение нормальной статической типизации в систему шаблонов. Все те гигантские error'ы, которые вылазят, если в шаблон передать не то что ожидается — прелести динамической типизации:)
Минимум сущностей вот здесь не согласен. Поля, методы и свойства — это разные сущности, пускай и будут разными. Делать все поля приватными насильно — не хочу.
Макросы однозначно да. Я писал об этом статью со своим видением, впрочем с тех пор уже кое-что поменялось, да и в дискуссии выяснились некоторые дополнительные факты — в частности, людям нужен универсальный код, который можно выполнить и в runtime и в compile-time.
Функции внутри функций Ну это вообще очевидная вещь. В расширениях GCC она реализована давно, но в стандарте до сих пор нет. Почему?
Substructural type system пока не очень понятно
Сборка однозначно не так как в С++. Во всех следующих языках все сделано гораздо лучше.