Да, да! Нового синтаксиса не добавляется а live функции что-такое? А в C++ они тоже есть? Если вы не заметили то я про C++ спрашивал, а не про D.
И по вашей ссылке
> Если функции @ live, вызывают функции, не являющиеся @ live, ожидается, что эти вызываемые функции будут представлять собой @ live-совместимый интерфейс, хотя он не проверяется
Предполагаем что все хорошо, но не проверяем. Как-то попахивает текущим плюсовым походом и безопасность стремительно улетучивается.
> Ахах, конечно есть
Без предоставления стандартной библилотеки, удовлетворяющей правилой новой семантики у вас будет куча кода unsafe (почти весь) и чего вы добьетесь в этом случае? Правильно, ничего.
Нельзя избежать оверхеда на C# абстракции и рантайм вносят свою лепту. Можно только приближаться по производительности к нативному коду. И инструментарий языка будет ограничен практически только конструкция для работы на стеке предаллоцированные массивы, struct, ref struct и span'ы.
В сравнении с такими абстракциями программировать на расте гораздо веселее.
Т. е. вы предлагаете создать отдельное подмножество языка со своей семантикой несовместимой со всем остальным языком, которое будет гордо называться, например, C++ SAFE. Для которого будет своя стандартная библиотека, нужно будет писать враперы (склеивающий код) с существующими библиотеками на C++. И в чем смысл сего действа тогда? NIH синдром?
> Это действительно хороший вопрос. Многие считают, что С++ уже не исправить. Лично я так не считаю и своим развитием С++ показывает, что он умеет эволюционировать. Смысл в том, что C++ сейчас как раз и движется в сторону многих вещей, которые Rust уже предлагает.
Прям интересно стало. Как вы предполагаете встроить borrow checker в С++? Потому что без этого либо производительность, либо безопасность будут страдать.
Уровень аргументации спустился ниже плинтуса, пробил дно и устремился к центру Земли, извините.
Если оппонент там уже находится, приходится идти ему настречу.
Они не «подобраны, чтобы вызывать ассоциации», извините. Они-таки являются либо словами английского языка, либо чем-то, порождённом из английского языка.
Если язык Б произошел от языка А. Это совершенно не значит что в языке Б все слова должны совпадать с языком А. У языка Б могут быть похожие слова, которые одинаково или похожим образом пишутся или читаются. И при этом они могут обозначать разные вещи (да со временем языки могут расохдиться это естественный процесс). Так что это именно слова языка Б похожие на слова из языка А. Так их просто удобнее и можно более гибко воспринимать.
Не нравится, что ключевое слово (именно полноценное слово на языке rust) mut вызывает не совсем правильную ассоциацию? Ну так проявите гибкость ума и придумайте более подходящую ассоциацию. Например: Mono UniT.
Даже не привязываясь к конкретным примерам. Подумайте чисто логические. Предположим, у вас есть функция принимающая несколько ссылок и соотвественно с несколько лайфтаймов. Отсюда сразу же вытекает, что у этих лайвтаймов могут потенциально быть разные отношения сабтайпинга (кто-то из ссылок должен жить дольше другого, а какие-то могут быть не связаны между собой). И эти отношения логично могут выводиться по разному в зависимости от реализации (по вашему утверждению) и поэтому не отражаются в сигнатуре явно. А дальше
Если мы выводим лайвтаймы по реализации функции, то получается мы можем сломать код изменив немного тело функции внутри и не меня сигнатуру функции. И мы не можем сделать заглушку для функции, а потом ее реализовать иначе потенциально может потребоваться переписывать весь внешний код. По вашему это нормально?
Хорошо. А теперь давай на этот вывод лайвтаймов посмотрим под другим углом. Если мы выводим лайвтаймы по реализации функции, то получается мы можем сломать код изменив немного тело функции внутри и не меня сигнатуру функции. И мы не можем сделать заглушку для функции, а потом ее реализовать иначе потенциально может потребоваться переписывать весь внешний код. По вашему это нормально?
Как-то попахивает такое техническое решение сами знаете чем.
Никогда не понимал, почему любители покритиковать синтаксис какого-либо языка программирования считают эталоном английский язык? Почему не хинди или китайский (самый распростраенный)?
Кроме того вы не замечали, что наиболее часто используемые слова в языке стараются сделать (или уже сделали) короткими I, we, you, they, it, if, и т. п. Я правильно понимаю, что они какаие-то слишком короткие в английском и их хорошо бы удленнить для… эмм, написания текстов в стиле Толстого?
К тому же вы никогда не пользуетесь сокращениями? Может стоит попробовать :-)
Говорят в гос. структурах любят использовать сокращения и им норм. Почему? Да потому что они знают как эти сокращения расшифровываются и это им позволяет эффективнее общаться. Да, это напрягает обычных людей. Но языки программирования не нужны обычным людям. Они нужны программистам, которые знают что означают те или иные ключевые слова и где они могут использоваться.
И все-таки почему большинство таких фанатичных любителей подокапываться до синтаксиса языков считает, что нужно стремиться, чтобы текст на языке программирования был похож на английский текст? Они ведь разные задачи решают? И ключевые слова на языке программирования это не английские слова. Это слова на языке программирования (другом языке, не английском, с другой семантикой и другими задачами). Да ключевые слова подобраны, чтобы вызывать определенные ассоциации с английскими словами. С установлением ассоциативных связей, как мне кажется, ключевые слова справляются на ура. Да, может быть сами слова для ассоциаций не всегда выбраны абсолютно точно, но это уже другой вопрос.
> Нормальный текст, на русском или английском языке, в таком стиле, никто, в здравой уме и твёрдой памяти удобочитаемым бы не назвал. В этом-то и проблема.
Строго формальные вещи (которые в том числе описыватся на языках программирования) даже математики на естественных языках не пишут. Они для этого придумали язык теоретико-множественных обозначений. Странные эти люди — ученые… Серость. Да?
К сожалению, аналогия не пошла на пользу. Есть вещи которые фиксируются при роздении (релизе) и потом уже в течении жизни никогда не поменяются.
Вам уже выше пытались объяснить, что понятие «красоты синтаксиса языка» (которое вы пытаетесь ввести) слишком субъективно и разплывчато. И поэтому не имеет особого значения.
А с точки зрения скорости чтения кода и понимаемости синтаксис раста вполне нормальный. Не возникает вопросов это объявление структуры или вызов функции или что-то еще. Что тут еще обсуждать? А главное с какой целью? Совершенно не понятно.
Странный вы человек. Порой умные мысли говорите, а порой такие странные высказываете. А еще вы как-то лицом не очень вышли. Вот если бы в выглядели как Ада или как Паскаль… почему бы это не обсудить?
Т. е. по-вашему заката Кобола еще не было?
Тогда какую, по вашей оценке, долю рынка, на котором присутстует Кобол, он занимает в процентном выражении от общего числа разработчиков на этом рынке?
И что по-вашему закат ЯП?
Что это? Упрощенная форма CSP? Только флажком коммуницируем между параллельными потоками? Расшаренный стейт вообще нельзя? А что если, у меня например большой стейт в памяти и я хочу к нему периодически обращаться из нескольких потоков, но при этом держать его копию для каждого потока это много. Как тогда быть?
using System;
public class Program
{
public static void Main()
{
var myVariable = 10;
Console.WriteLine(nameof(myVariable1));
}
}
не скомпилируется с ошибкой:
Compilation error (line 8, col 28): The name 'myVariable1' does not exist in the current context
Compilation error (line 7, col 7): The variable 'myVariable' is assigned but its value is never used
И по вашей ссылке
> Если функции @ live, вызывают функции, не являющиеся @ live, ожидается, что эти вызываемые функции будут представлять собой @ live-совместимый интерфейс, хотя он не проверяется
Предполагаем что все хорошо, но не проверяем. Как-то попахивает текущим плюсовым походом и безопасность стремительно улетучивается.
> Ахах, конечно есть
Без предоставления стандартной библилотеки, удовлетворяющей правилой новой семантики у вас будет куча кода unsafe (почти весь) и чего вы добьетесь в этом случае? Правильно, ничего.
В сравнении с такими абстракциями программировать на расте гораздо веселее.
Может есть какие-то более практичные варианты?
Прям интересно стало. Как вы предполагаете встроить borrow checker в С++? Потому что без этого либо производительность, либо безопасность будут страдать.
`&str` — это строковый слайс
Если оппонент там уже находится, приходится идти ему настречу.
Если язык Б произошел от языка А. Это совершенно не значит что в языке Б все слова должны совпадать с языком А. У языка Б могут быть похожие слова, которые одинаково или похожим образом пишутся или читаются. И при этом они могут обозначать разные вещи (да со временем языки могут расохдиться это естественный процесс). Так что это именно слова языка Б похожие на слова из языка А. Так их просто удобнее и можно более гибко воспринимать.
Не нравится, что ключевое слово (именно полноценное слово на языке rust) mut вызывает не совсем правильную ассоциацию? Ну так проявите гибкость ума и придумайте более подходящую ассоциацию. Например: Mono UniT.
Как-то попахивает такое техническое решение сами знаете чем.
Кроме того вы не замечали, что наиболее часто используемые слова в языке стараются сделать (или уже сделали) короткими I, we, you, they, it, if, и т. п. Я правильно понимаю, что они какаие-то слишком короткие в английском и их хорошо бы удленнить для… эмм, написания текстов в стиле Толстого?
К тому же вы никогда не пользуетесь сокращениями? Может стоит попробовать :-)
Говорят в гос. структурах любят использовать сокращения и им норм. Почему? Да потому что они знают как эти сокращения расшифровываются и это им позволяет эффективнее общаться. Да, это напрягает обычных людей. Но языки программирования не нужны обычным людям. Они нужны программистам, которые знают что означают те или иные ключевые слова и где они могут использоваться.
И все-таки почему большинство таких фанатичных любителей подокапываться до синтаксиса языков считает, что нужно стремиться, чтобы текст на языке программирования был похож на английский текст? Они ведь разные задачи решают? И ключевые слова на языке программирования это не английские слова. Это слова на языке программирования (другом языке, не английском, с другой семантикой и другими задачами). Да ключевые слова подобраны, чтобы вызывать определенные ассоциации с английскими словами. С установлением ассоциативных связей, как мне кажется, ключевые слова справляются на ура. Да, может быть сами слова для ассоциаций не всегда выбраны абсолютно точно, но это уже другой вопрос.
> Нормальный текст, на русском или английском языке, в таком стиле, никто, в здравой уме и твёрдой памяти удобочитаемым бы не назвал. В этом-то и проблема.
Строго формальные вещи (которые в том числе описыватся на языках программирования) даже математики на естественных языках не пишут. Они для этого придумали язык теоретико-множественных обозначений. Странные эти люди — ученые… Серость. Да?
Вам уже выше пытались объяснить, что понятие «красоты синтаксиса языка» (которое вы пытаетесь ввести) слишком субъективно и разплывчато. И поэтому не имеет особого значения.
А с точки зрения скорости чтения кода и понимаемости синтаксис раста вполне нормальный. Не возникает вопросов это объявление структуры или вызов функции или что-то еще. Что тут еще обсуждать? А главное с какой целью? Совершенно не понятно.
Тогда какую, по вашей оценке, долю рынка, на котором присутстует Кобол, он занимает в процентном выражении от общего числа разработчиков на этом рынке?
И что по-вашему закат ЯП?
Действительно грубо.
А можете привести пример проекта вот с этими свойствами (желательно со ссылками, подтверждающими эти свойства):
Интересно узнать о проектах какой сложности идет речь.
Увы эта реализация не похожа на
nameof
из C#выведет в консоль
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3ffad15450a43fabab337e37e22440aa
а C# код
не скомпилируется с ошибкой:
https://dotnetfiddle.net/UHBtJh