Я повторю еще раз тезис, на который вы категорично ответили «нельзя»:
можно иметь имя сначала, не имея «синтаксического мусора» перед именем.
Мне без разницы кто там и что говорил. Я говорил а) в рамках контекста определённым начальным комментом, б) я отвечаю только за свои тезисы.
С чего вдруг вы решили, что вы можете в любой момент подменить начальный тезис и что-то мне предъявлять? Ваши манёвры меня волнуют мало.
Имеет; таким образом список идентификаторов синтаксически отделяется от типа,
В го? К тому же мы говорим про двоеточие в :=, а не о том что вы там себе напридумывали. Этот костыль можно впилить в какой угодно синтаксис — хоть в си. Он вообще никак не привязан ни к чему.
А это (существование какой-либо проблемы с var name =) опровергает Rust,
Опять поток шизофрении. Чего он там опровергает? Там есть let, который такая же подпорка для синтаксиса. И есть избыточность let name: type, когда как в си это type name.
Если бы упоминаемая вами проблема реально существовала, её пришлось бы решать не только в Го, но также и в Расте.
Как же быстро лозунги меняются. То := меня опровергает, то уже меня опровергает раст.
Каким образом из отсутствия решения следует отсутствие проблемы? Вы вообще в логику можете?
Как я уже говорил, я не будут отвечать на догматы фантиков уровня «это не мусор — это важный элемент», «мы не воспринимает это как отдельный элемент» и прочий бред.
о том что «let/var» нужен в обоих вариантах
Пруфы.
но в паскалевском стиле он используется единообразно во всех ситуациях
var v1 int = 100
v1 := 100
Единообразно, да. Объясняйтесь.
а в C является в некотором роде костылём, подпирающим конструкцию, из которой убрали необходимый элемент — тип обявляемой переменной
Обоснования этому набору слов. Что именно является костылём, что там и где и что подпирает.
И ответа на самое главное нет — каким образом := относится к паскаль-стилю? Это просто костыль, который можно впилить в какой угодно стиль. Причём тут паскаль-стиль? Как это выступает за паскаль-стиль, но против си-стиля?
Это скорее у вас дыра в понимании. Семантика двоеточия зависит от контекста: для переменных отделяет тип, для функций — тип возврата.
С чего вдруг она меняется? Основание.
Полный тип может включать в себя больше чем то, что после двоеточия, но правило то же:
Т.е. двоеточие не имеет никакого отношения к типу. Из этого прямо следует, что тип не только справа от двоеточия, либо только. Третьего не дано. Либо двоеточие ничего не значит.
Что самое интересное — эти манёвры следствие попытки оправдать неоднозначность, которой там, на самом деле, нет. Т.к.: там там же отделяет тип. И типом является именно возврат, ведь тип возврата и определяется. Аналогично работает и для ?:type. Когда? является признаком опциональности и точно так же относится к имени, а не определяет ?:type — новый синтаксис для типа. Потому что тогда нужно было ?type, либо type?..
справа от имени — всё, что про тип, т.е. про область всех возможных значений. Для скаляров — просто имя уже имеющегося типа (встроенного или определённого). Для агрегатов — перечисление типов членов агрегата. Для функций (которые есть мост между двумя областями, входом и выходом) — как типы аргументов, так и тип возращаемого значения.
Вам не нужно мне перечислять те случаи, где его семантика потекла — я и так это знаю. Нужно отвечать на вопрос а) зачем оно нужно. б) почему у него изменяется семантика.
слева от имени — то, что про сам объёкт. Например категория (var/const/enum/function/struct/class), видимость объекта (public/private), модель хранения (static/const/readonly), модель передачи параметра (in/out/ref), модель вызова метода (virtual/static) и прочee. Всё это не является частью типа.
Всё это хорошо, но без интеграции в предыдущие рассуждения — это просто перечисление не относящиеся к теме. Интегрируйте его в изначальную вашу модель. public — это категория? Что это?
К тому же, вы так и не обосновали разделение в таблице. На каком основании часть после двоеточия вынесена, а список параметров остался.
В результате первого правила функции получают настоящий тип
Какие критерии для «настоящий»? Почему меня должен волновать какой-то фентезийный «настоящий тип».
а не несовместимый «тип-объект с расширениями»
У вас опять рассуждения потекли. Вы там забыли про ref/const и прочее. Это такие же «расширители» и без ник никакая аннотация типа не определяет объект, а является лишь частью определения.
, становятся гражданами первого сорта, могут быть присвоены переменной, проверяются при присваивании как по параметрам, так и по возвращаемому значению, иначе будет ошибка типа.
Ну во-первых это наивные манипуляции, когда сравнивается несравнимое. Т.е. берётся скриптуха и её примитивная модель и сравнивается с более сложной моделью, при этом примитивность и её следствия превращаются в следствия синтаксиса/«настоящих типов».
И, заодно, массивы теперь получают полноценный тип, как и любой другой агрегат или строка (массив символов), а не «тип-объект», чей тип при передаче в функцию внезапно протухает и разлагается до указателя.
Опять же. Сравнение примитивной скриптухи и более сложной модели.
Но очевидно, что name?: type — это просто сахар для каноничной записи name: type | undefined, который слишком часто встречается и слишком длинно писать каждый раз. Правило 1 выполняется: ?:type находится справа от name.
Я не понимаю две вещи. На каком основании вы дёргаете куски фраз и отвечаете только на удобное. Зачем вы мне повторяете то, что я уже до вас вам сообщил?
Можно, конечно, делать это делать слева до :, как многие и делают. Но, очевидно, что получается полный треш. Всякие там name?: type.
Здесь именно говорится о том, что ?: — справа от name. И именно поэтому этот пример называется трешем.
При этом это я говорил про этот: [Int, ?:Bool], никакого name тут нет. А вот лево есть. Тут, конечно, можно пытаться задним числом опять изменять семантику для :, но очевидно — что это эквивалент name?:type и значит это не type|undefined, а именно опциональный аргумент. Мне лень читать и искать это в мануале, но любо это дыра в логике языка, либо действительно так.
Параметрами тоже слева?
С чего вдруг? Опять нелепая попытка дёргать фразы. Расширения — это квалификаторы, в разных контекста это понятия значит разное.
Упс, строгая логика поломалась
То, что вы увидели где-то два похожих слова и вам показалось, что вы что-то там нашли — это лишь вам показалось.
— параметрами расширяем таки справа, т.е. внутри (). И теперь у нас расширения то слева, то справа.
С чего вдруг она справа, если они внутри? Отсчёт идут от () — очевидно, что внутри никаким образом не может быть ни справа ни слева.
Вы уверены? Я плюсовик, не голый сишник, но насколько мне известно, ANSI C не позволяет функциям возвращать массив,
Я уверен. К тому же у вас опять какие-то проблемы с восприятием. Мы говорим о синтаксисе, а не о том, что си позволяет/не позволяет делать. Синтаксис это позволяет.
только указатель, и объявление будет примерно таким монстриком
Основания в студию.
: void (*f())[N]. В высшей степени интуитивная конструкция.
Да, куда более интуитивная, чем рандомный набор символов и дыр, который существует в скриптуха-паскаль-языках.
Конечно, куда там этим конструкциями до *[N]void f(); — вот оно, чудо человеческой мысли.
Или это: []int{1000, 2000, 12334} как перепаста с сишного (int[]){1000, 2000, 12334}. struct{f int}{50} — вот оно, удобство.
Претензию про ref и override так и не понял: что конкретно вам не нравится, и как именно они ломают логику?
Я уже обозначил выше проблему — как это интегрируется в вашу табличку.
Есть другой подход: compiler as a service, как это сделано в C#/TypeScript.
Именно этим и занимается clang уже 10лет. Да и уже лет 20 есть gcc-xml, которого для базовых вещей вполне хватит. Причём лучше, чем упомянутые выше случаи.
Тут двойной факап. И упоминания С++, который находится в авангарде «compiler as a service» и догматическая уверенность в одном избранном случае.
А как прочесть запись bool f(int, string) в парадигме «тип имя»? «Функция типа bool с именем f»? Но беда: тип этой функции не bool, а вовсе даже bool (int, string).
У вас дара в логике.: — семантически отделяет тип. Вы игнорируете сей факт и свободно подменяете семантику: во имя подбития реальности под свою модель.
К тому же, вы взяли какую-то логику и каким-то образом определили её за правильную, а далее исходите из того, что всё что иное — неправильное. Ведь любая другая логика — неправильная.
С таким же успехом можно сказать про ref и про override и прочее. Вы говорите о каком-то примитивном обрубке, а не о каких-то общих правилах.
В общих правилах определяющим является имя, а уже далее что-то там из него следует. Но если имя является определяющим, то на каком основании оно должно быть вначале? Да ни по каким — это догмат.
Начнём с того, что сишный синтаксис создан как f(a, b) {} — изначально все типы были auto(из крестов). Правда там не было вывода типов, а универсальный тип просто был интом.
Всё что слева/справа ничего не значит. При этом в си есть прямое разделение на право и лево. Есть тип, а есть объект. То, что написано справа — относится к объекту, а всё что слева — к его типу.
В примитивных языка такого разделения нет — на то они и примитивные. В том же bosque разделение уже появляется — там есть тот же ref, т.е. то, что относится к самому объекту.
Можно, конечно, делать это делать слева до :, как многие и делают. Но, очевидно, что получается полный треш. Всякие там name?: type.
Правда в Си всё не совсем так. Там тип не может быть массивом, потому что массив — это объект. Так же как типом не может быть функция.
Хотя, конечно, в си есть и тип-функция и тип-массив, но только в рамках тайпдефа. Так же, есть (int[]){} — это логика исходит из того же. По такому же принципу работает using в С++.
Если проще. Объект может переменной — это просто тип. Если мы видим просто тип — это тип какого-то объекта/переменной.
Но, в случае с [] — типом будет массив. Объект будет массивом. А типом указывается тип возврата операции/тора [], аналогично и с () — скобочки уже из объекта делают функцию. А всё остальное к делу отношения не имеет. Тип, который слева — это не тип объекта — это тип возвращаемый (). Потому что свободный тип — это всегда объект(какого-либо значение).
Поэтому си читается следующим образом. void f(); f — это идентификатор/имя. Вы без проблем можете писать void f()[] — функция будет возвращать массив. Тоже самое с [][], вы можете написать int arr[10]() — тоже без проблем.
И это бы всё работало круто, но в си есть фундаментальное разделение. Есть объекты как значения(которые могут быть значениями), а есть которые не могут. Вот [] и () значениями быть не могут.
Таким образом сишный синтаксис и его семантика куда строже и логичнее, нежели упомянутая вами. Где вы как угодно трактуете каждую закорючку.
Описать его можно так. Есть база, которой вы даёте тип. Тип задаётся как справа так и слева. Причём есть два типа типов. Тип самого объекта(массив/переменная(значение)/функция), который пишется справа. И всякие расширения — это слева.
f() — это функция, тип объекта. Слева накидываются всякие свойства, свйоства накидываются ИМЕННО на объект(это упомянутая мною база). f тут уже вообще не при делах.
() — расширяется параметрами. Так же, он возвращает какой-то объект. Тип объекта справа не написан — значит это обычный объект/значение. Этот объект является базой. Ему можно задать тип и всякие там квалификаторы.
* — это тип. Никаких «на» там нет. Это просто упрощение. * — такая же база. Правила те же, но она слева и приоритет у неё меньше. Именно для этого там скобочки — они выделяют новую базу.
И теперь, я думаю, вы сами сможете прочитать bool f(int, string)
База по умолчанию — идентификатор. Идентификатор имеет тип-объект функция. f — это функция, () — имеет семантику «аргументы и „возвращаемое для операции () значение“(по-колхозному возвращает значение)». Читаем аргументы. Аргументы типа инт и строка. Далее эта функция что делает? Возвращает значение(справа ничего нет). Далее, слева могут стоять уточняющие, а именно тип значения и его квалификаторы.
Так же там могут стоять «квалификаторы», которые воздействуют на сам базовый объект.
f — функция с аргументами инт и строка, возвращающая(по-колхозному) значения типа bool.
Это не код, это говно (неинициализированная переменная).
Т.е. ответа нет и адепт го порвался?
А что касается того, что опровергает Go, то Go опровеграет два ваших утверждения:
Фантазии брызжущих слюной адептов го.
1) необходимость мусора в виде двоеточия, отделяющего имя переменной от типа
Я уже отвечал на эту ахинею. Эта ахинея никак не связана с темой и с моим утверждением, т.к. она применима не только к паскаль-стилю.
Т.е. я могу использовать := в любом из стилей. Это просто сахар, костыль. Определяются переменные го не так.
2) необходимость мусора в виде ключевого слова типа let, var или auto.
Что за нелепая попытка врать. Читаем мой коммент:
Ни от какого auto паскаль-стиль не уходит, а наоборот требует ввод кейворда для обозначения декларации переменной. Таким образом вы всегда будите писать синтаксический мусор вместо типа. Всякие там var, let и прочее.
Т.е. брызжущий слюной адепт го врёт, утверждая, что говорил «необходимость мусора в виде ключевого слова типа let, var или auto.», но я приводил это лишь как пример.
Двоеточие в := не является отдельным элементом/ключевым словом.
Является.
Два символа := являются одним, единым оператором, поэтому никакого мусора при его использовании уже нет.
Два символа в if «являются одним, единым оператором». Опять методичка потекла.
Два символа := являются одним, единым оператором, поэтому никакого мусора при его использовании уже нет.
Он и есть мусор, т.к. есть уже оператор =. А это другой оператор, который является костылём для решения избыточности паскаль-стиля.
(Не будете же вы настаивать, чтобы присвоение значения переменной выполнялось вообще без единого оператора?)
Опять чушь. Именно те, кто рассказывал про «проблему auto» утверждали, что переменную можно объявлять без избыточности.
Я же сообщил, что это неверно и нужен механизм отделения. В ситуации же си-синтаксиса механизм ненужен — он уже есть.
В ситуации же с паскаль-синтаксисом он нужен. Это var/let и прочая фигня. Именно с var сделан ваш го. А далее закостылено := — которая является таким же механизмом, лишней сущностью она повторяет уже существующие функционал.
Вообщем, вы, насколько я погляжу, особо вменяемостью не блещете. Спорить о чём-то с ботами бесполезно, поэтому я вернуть к сити, а именно.
Я отвечал изначально в контексте преимущества паскаль-стиля, т.е. я это опровергал. Теперь вам нужно сообщить — каким образом := относится к паскаль-стилю? Я заранее отвечу — никаким. Новы там можете попытаться что-то придумать.
Я даже не поверить, что я отвечаю на настолько нелепые рассуждения.
Есть синтаксис var name type =, базовый. Данный пациент утверждает, что никакой избыточности нет. Но авторы го с ним несогласны.
Именно поэтому вводится var (), это есть ещё со времён паскаля. Потому что все очевидно, что объявление с аннотацией через var — это избыточно. Т.е. пациент спорит с объективной реальностью.
Аналогично с := — это синтаксический сахар, который был добавлен специально для решения проблемы var name auto =.
Т.е. мы имеем как минимум два варианта объявления переменных, но что же там нам сообщал пациент:
В Go объявление функции, объявления типа указателя на функцию, передача функции как объекта первого порядка — все это идентичные синтаксически вещи
Он заявлял, что проблема С++ в том, что синтаксис разный. В целом эти базовая методичка го «делаем что-то одним способом», но.
Как мы видим, что тут эта методичка ломается. Потому что способов как минимум 2(3). А почему? Потому что общий случай избыточен и добавлен специальный сахар для решения проблемы.
Во-первых, не мусор, а однозначность синтаксиса как для парсера, так и для человека.
Мусор. Вы как бот повторяете один и тот же набор шаблонных фраз.
Во-вторых, писать это несравнимо проще auto.
Основания этим заявлениям.
В-третьих, таки ничего лишнего перед именем переменной нет.
Есть после имени. До оно, либо после — это ничего не значит.
Это ли не тот синтаксический мусор.
Нет, вы действительно бот. Какое отношение эти рассуждения имеют к теме? Никакого. Абсолютно неважно что они значит — они значат тоже самое, что и :=, только ещё больше.
Вместо типа мы пишем вещи, которые вообще не имеют никакого отношения к делу.
Чушь какая. Они имеют отношения к делу и никто их вместо не пишет. Вам лишь сообщили, что подобная логика объявления без типа существовала и существует в си.
Модификаторы доступа и устаревшие ключевые слова, которые нынче ничего не значат.
Вы опять где-то что-то услышали и начали повторять? Ну расскажите мне про то какой бесполезный статик, либо const, либо volatile. Или это, как обычно, пустой трёп?
В этом нет логики, это синтаксические извращения.
Опять же, когда нечего сказать — пиши херню.
В Го однозначный синтаксис, которые имеет четкие правила — либо :=, либо var. Все. Пример тут не с кого брать было.
Всем, кто потом будет работать с инструментами, которые язык парсят и что-то делают с AST. Таких для Go множество и именно благодаря его однозначному и простому синтаксису. Это ускоряет и сам процесс парсинга, что полезно вообще всем.
Попросту враньё. Инструментов по статическому анализу С++-кода больше и они куда как мощнее и качественнее, чем для го. Никакой С++ парсить ненужно.
К тому же, это враньё ещё и тем, что в го нужны парсеры потому, что язык крайне примитивен и ничего не может. От того и нужнается в кодогене и тысячах костылях, для обхода отсутствия тех же генериков.
Никакого опровержения не заметил. Отсутствие неоднозначности в синтаксисе языке несет за собой далеко идущие преимущества. И Go этому яркий пример.
Т.е. у вас ничего, кроме лозунгов, нет? Где преимущества, в чём преимущества? Го в сравнении с тем же жаваскриптом/тайпскриптом — пыль. Я уж не говорю про С/С++. Что мне показывает пример го? Да ничего.
То, что парсить легко. Дальше логику сами можете достроить.
Ну то, что ваши тезисы — глупые лозунги я понял уже давно. Вы не на баррикадах и лозунги в данном случае котируются мало.
В том, что в С/С++ синтаксис указателя на функцию ужасен
Примеры. Зачем мне лозунги? Конкретно. Берёте идентичный код и пишите его на го и на С++.
нечитабелен
Опять лозунги?
сложен для написания и полностью отличается от того, как функции объявляются.
Вы ведь ничего не знаете. Функция объявляется так же.
Чего стоит только необходимость включения имени переменной в сам тип вроде int(*foo)().
У вас явно лозунги плывут. Функции в си записывается как int(foo)(); Указатель записывается как int(* foo)(); То, что вы этого не знаете — это проблему. Узнайте/спросите перед тем, как делать далеко идущие заявления.
В Go объявление функции, объявления типа указателя на функцию, передача функции как объекта первого порядка — все это идентичные синтаксически вещи, что значительно упрощает чтение и написание кода.
Опять лозунги. Приведите пример.
Авторы Go к этому стремились, делая такой синтаксис, и они своего добились.
Это настолько нелепые заявления. Синтаксис го не может и 10% того, что может синтаксис си в С++, в том же C#. Зачем сравнивать несравнимое?
Это примерно как рассказывать, что у мышки 3 кнопки, а у клавиатуры 100. Вот ведь какая клавиатура плохая — кнопок много. Авторы мышки стремились сделать такое кол-во кнопок(малое) и они добились этого.
Все ваши рассуждения — пустые общие слова, которые ничего не значат.
Помимо этого, С++, будучи заложником своей извращенной грамматики, придумал тот ужас, которым называют лямбды в этом языке. Тоже самое в C# том же, хоть и не настолько ужасно.
Она извращённая лишь потому, что вы где-то это услышали? Сильная аргументация.
И да, у вас опять лозунг потёк. Покажите мне эквивалент С++-лямбды на го, либо на другом языке.
Пример го показывает, как можно иметь имя сначала, не имея «синтаксического мусора» перед именем.
Нельзя. := — это синтаксический мусор, который, к тому же, писать сложнее нежели =, либо auto.
К тому же, как я уже говорил — мы либо вводим :=/=, либо мы имеем не только := в качестве синтаксического мусора, но и аннотацию при которой := избыточно.
Двоеточие это только пример реализации первого подхода.
Это так же неверно, т.к. двоеточие не имеет никакого отношения к подходу.
Я больше скажу — в си вообще аннотация типа ненужна. Она используется только для в одном случае — определение. Да и то нужен просто какой-то флаг для выражения намерения. Подойдёт вообще что угодно. const/auto/register. Всё это уже придумано и давно. Го просто взял эту логику из си.
Я уже объяснял — это не работает. Причин тому масса. Основная из них заключается в том, что как звучал тезис? «имя: тип что-то там позволяет». := — опровергает этот тезис, т.к. в данном случае абсолютно неважно где и как написан тип — одного «имя: тип»/«имя» недостаточно для определения переменной.
К тому же, := — является таким же кейвордом, о котором я говорил. И абсолютно неважно в каком он будет виде. Т.е. мой тезис это никак не опровергает.
К тому же, это вообще находится за рамками контекста т.к. контекстом является а) синтаксис принятый в обсуждаемом языке, б) синтаксис принятый в си.
Так же, := — избыточен для ситуаций, где тип не выводится, а задаётся. Вам придётся либо использовать избыточность, либо вводить два типа операторов, что опять же — избыточность и синтаксический мусор.
К тому же, это локальные го-заморочки не присущи ни паскалю, ни всему тому, что используется его стиль.
А так же, самое важное — это вообще никак не зависит от стиля. Это работает в любом случае. Т.е. смысла приводить это в контексте разделения стилей нет — т.к. это не относится к одному из — это относится к обоим.
И расшифруйте выражение "^hru_hru" — так, чтобы каждому обозначению соответствовало слово.
Дак вы должны это сделать — как я буду читать непонятно какие, придуманные вами, символы?
а теперь прочитайте как все обычные люди слева направо
Как нам разница — как и кто читает? К тому же нужно отличать чтение от понимания. Читать можно как угодно. К тому же, прочитайте мне 123.123. Прочитай мне a + b * (c + d).
Я могу читать как угодно, как и любой другой человек. И все именно так и читают. Читают таблицы сверху вниз, либо таблицы нужно запретить? Ищут ключевые слова в текста. Запоминают контекст.
А теперь попробуйте сделать это c выражением hru_hru*. У вас это не получиться.
Указатель — это тип *, T — это тип возврата операции разыменования. Слева всегда стоит конечный тип. Сишные определения читаются как математические выражения. Вот паста, где я разбирал «как читать».
Паста
// Нужно понять фундаментальную вещь - есть база, это некий контекст который расширяют расширятели типов.
//по дефолту база - это то, что справа. Базой любого типа является определение(имя).
typedef int f_t();//функция. База - имя. () - расширяет имя, делая его функцией. Функция теперь является базой.
// Для этой коснтрукции с лева пишется тип возврата:
f; //имя
f0();//функция.
int f1();//функция с типом возврата.
* f2();//функция с типов возврата "указатель".
int * f3();//для int базой является * - определение типа операции *(разименования) у указателя.
typedef int f0_t();//правила аналогичны. Функция.
//хотим сделать указатель на функцию
typedef int * fptr_t();//базой является функция - определяется тип возврата. Указатель.
//нужно как-то определить базу для *, чтобы она была именем. Ведь имя должно быть не функцией(как сейчас), а указателем.
typedef int (* fptr0_t)();//база для * имя. Далее скобки выступают базой.
//определяется тип операции * у указателя. Указатель является базой.
typedef int (** fptr1_t)();//мы определил тип операции * для указателя(который слева от fptr1_t).
// Базой является тип операции * для указателя, которая является типом операции * для указателя, который является типом для fptr1_t
typedef int (** fptr2_t[])();//fptr2_t теперь является массивом. Массив - база. Слева у массива определяется тип элемента массива.
typedef int (** fptr3_t[][7])();//здесь можно просто упростить до "fptr3_t - двойной массив". Двойной массив - база. Свйоства аналогичным одинарному.
typedef int * (** fptr4_t[][7])();//базой является функция. Для неё определяется тип возврата. Мы определили тип возврата - указатель. Далее мы уже знаем. int тип операции * для указателя.
typedef int * (** fptr5_t[][7])()[];//базой является функция. Типом определён указатель. Это не то, что мы хотели.
//мы хотели определить тип не для функции, а для типа операции * у указателя. Нам нужно сделать базой указатель.
typedef int (*(** fptr6_t[][7])())[];//база указатель. Типом для базы определяется массив. Массив база - для базы(массива) определяется тип элемента - int
typedef int * (*(** fptr7_t[][7])())[];//база массив. Для массива определяется тип элемента - указатль. Для указателя определяется тип операции *.
//тут можно вывести два правила. Право имеет приоритет. Для лева - базой является то, что справа. Для права - лево.
int a[1];//имя - база. Справа - массив. База массив. Для него определён тип - инт, как тип элемента массива.
int ((a)[1]);//можно руками определить базы, как это делается по-дефолту.
int * b[1];//b - база. Для неё определён массив. Для массива определён тип(элемента) - указатель. Для указателя определён тип операции* - int.
int (*c)[1];//c - база(имя). Для неё опредён тип - указатель. Для указателя определён тип операции* - массив. Для массива определён тип элемента - int.
В этом то вся и проблема. Некоторые последователи С++ именно, что могут только «парсить» текст.
Лозунги такие лозунги.
А забыли, что 99% текст не парсят, а читают.
Я вам привёл примеры — почитайте их. Не нужно путать чтение и интерпретирование. Читать можно что угодно и как угодно, но понимать вы будите так как нужно.
Так вот напоминаю вам что чтением в отличие от «парсения» является процесс восприятия информации слева направо.
Пустые заявления. Да и расскажите это арабам.
Поэтому можно написать только лишь предложение «Указатель на переменную хрю-хрю».
Вы ничего не знаете о си и эта формулировка — полная чушь. Ну и я жду срывов покровов на тему number[], жду чтения () => {}. Ваши рассуждения глупы и догматичны. Во-первых указатель ни на какие переменные не указывает. На этом уже можно закончить и признать вашу несостоятельность, полную.
И это будет для всех текст, только для вас набор слов.
Вы попросту хейтер, который придумал какую-то чушь и ему кажется, что его объяснения что-то объясняют, но нет. Хейтер просто услышал где-то про «паскаль читается, а си нет» и начал выдумывать чушь. Назвав набором слов всё, начиная от математики заканчивая каким-нибудь тайпскриптом.
И наоброт, предложение «Хрю-хрю на укаказатель переменную » -будет для вас текстом, а для 99% людей набором слов.
Это и есть набор слов. Вы пытаетесь рассуждать на тему, в которой ничего не понимаете, приводя идиотские примеры(это даже не примеры, а полный треш). Я отказываю даже читать этот набор слов пока там не будет нормальных примеров с объяснениями — что вообще этот набор слов значит и как он следует из тех же сишных определений.
Это какие-то попытки подменить изначальный тезис. Был пример со sturct — я показал, что в этом языке используется такая же форма определения объектов. Она используется везде, в том же тайпскрипте.
потому что слева от имени стоит не тип
Где тут: struct name — стоит слева тип? Нигде.
Начнём с того, что сишный sturct под неё подходит, а говорилось именно о нём. Так же никакое положение в таблице не обосновывается, никак. Т.е. на каком основании "(id: int, data: string)" является «domain», а bool не является. К тому же, ваша табличка игнорирует override method, ref env.
Ну и на самый главный вопрос нет ответа. Почему? Можно нарисовать какую угодно табличку, но вопрос заключается в том — почему так должно быть? Зачем строить свои рассуждения на догматах?
Что именно он опровергает? Поподробнее. Вводом := или подобной фигни? Ну дак это не опровержение — это подтверждение, т.к. это и есть кейворд для отделения декларации от использования. К тому же, он к делу отношения не имеет, т.к. почти во всех языках используется var/let. И говорим мы о таком языке.
Скорее в древних блокнотах. Современный редактор умеет в семантическую подсветку. А подсветка уровня кейвордов — это про древний блокнот.
Соответственно — function является лишним синтаксическим шумом, т.е. редактор умеет красить функции в уникальный цвет. И современно без разницы какие они.
Почему? К тому же везде и всюду сделано аналогично и здесь:
function update
entity Foo {
И так далее.
Например логично закодировать. Указатель на хрю-хрю как ^hru_hru. Или Хрю-хрю указывает на — hru_hru^. А если сделать обратный порядок, получиться чтение справо налево.
Распарсить это решительно невозможно. Это какой-то набор слов. Напишите что-то более адекватное типа «в крестах так: бла-бла, а нужно так: бла-бла».
Хорошо, поиграем.
С чего вдруг? Это лозунги и догматизм какой-то. Где обоснования?
Мне без разницы кто там и что говорил. Я говорил а) в рамках контекста определённым начальным комментом, б) я отвечаю только за свои тезисы.
С чего вдруг вы решили, что вы можете в любой момент подменить начальный тезис и что-то мне предъявлять? Ваши манёвры меня волнуют мало.
В го? К тому же мы говорим про двоеточие в :=, а не о том что вы там себе напридумывали. Этот костыль можно впилить в какой угодно синтаксис — хоть в си. Он вообще никак не привязан ни к чему.
Опять поток шизофрении. Чего он там опровергает? Там есть let, который такая же подпорка для синтаксиса. И есть избыточность let name: type, когда как в си это type name.
Как же быстро лозунги меняются. То := меня опровергает, то уже меня опровергает раст.
Каким образом из отсутствия решения следует отсутствие проблемы? Вы вообще в логику можете?
Пруфы.
var v1 int = 100v1 := 100
Единообразно, да. Объясняйтесь.
Обоснования этому набору слов. Что именно является костылём, что там и где и что подпирает.
И ответа на самое главное нет — каким образом := относится к паскаль-стилю? Это просто костыль, который можно впилить в какой угодно стиль. Причём тут паскаль-стиль? Как это выступает за паскаль-стиль, но против си-стиля?
С чего вдруг она меняется? Основание.
Т.е. двоеточие не имеет никакого отношения к типу. Из этого прямо следует, что тип не только справа от двоеточия, либо только. Третьего не дано. Либо двоеточие ничего не значит.
Что самое интересное — эти манёвры следствие попытки оправдать неоднозначность, которой там, на самом деле, нет. Т.к.: там там же отделяет тип. И типом является именно возврат, ведь тип возврата и определяется. Аналогично работает и для ?:type. Когда? является признаком опциональности и точно так же относится к имени, а не определяет ?:type — новый синтаксис для типа. Потому что тогда нужно было ?type, либо type?..
Вам не нужно мне перечислять те случаи, где его семантика потекла — я и так это знаю. Нужно отвечать на вопрос а) зачем оно нужно. б) почему у него изменяется семантика.
Всё это хорошо, но без интеграции в предыдущие рассуждения — это просто перечисление не относящиеся к теме. Интегрируйте его в изначальную вашу модель. public — это категория? Что это?
К тому же, вы так и не обосновали разделение в таблице. На каком основании часть после двоеточия вынесена, а список параметров остался.
Какие критерии для «настоящий»? Почему меня должен волновать какой-то фентезийный «настоящий тип».
У вас опять рассуждения потекли. Вы там забыли про ref/const и прочее. Это такие же «расширители» и без ник никакая аннотация типа не определяет объект, а является лишь частью определения.
Ну во-первых это наивные манипуляции, когда сравнивается несравнимое. Т.е. берётся скриптуха и её примитивная модель и сравнивается с более сложной моделью, при этом примитивность и её следствия превращаются в следствия синтаксиса/«настоящих типов».
Опять же. Сравнение примитивной скриптухи и более сложной модели.
Я не понимаю две вещи. На каком основании вы дёргаете куски фраз и отвечаете только на удобное. Зачем вы мне повторяете то, что я уже до вас вам сообщил?
Здесь именно говорится о том, что ?: — справа от name. И именно поэтому этот пример называется трешем.
При этом это я говорил про этот: [Int, ?:Bool], никакого name тут нет. А вот лево есть. Тут, конечно, можно пытаться задним числом опять изменять семантику для :, но очевидно — что это эквивалент name?:type и значит это не type|undefined, а именно опциональный аргумент. Мне лень читать и искать это в мануале, но любо это дыра в логике языка, либо действительно так.
С чего вдруг? Опять нелепая попытка дёргать фразы. Расширения — это квалификаторы, в разных контекста это понятия значит разное.
То, что вы увидели где-то два похожих слова и вам показалось, что вы что-то там нашли — это лишь вам показалось.
С чего вдруг она справа, если они внутри? Отсчёт идут от () — очевидно, что внутри никаким образом не может быть ни справа ни слева.
Я уверен. К тому же у вас опять какие-то проблемы с восприятием. Мы говорим о синтаксисе, а не о том, что си позволяет/не позволяет делать. Синтаксис это позволяет.
Основания в студию.
Да, куда более интуитивная, чем рандомный набор символов и дыр, который существует в скриптуха-паскаль-языках.
Конечно, куда там этим конструкциями до *[N]void f(); — вот оно, чудо человеческой мысли.
Или это: []int{1000, 2000, 12334} как перепаста с сишного (int[]){1000, 2000, 12334}. struct{f int}{50} — вот оно, удобство.
Я уже обозначил выше проблему — как это интегрируется в вашу табличку.
Именно этим и занимается clang уже 10лет. Да и уже лет 20 есть gcc-xml, которого для базовых вещей вполне хватит. Причём лучше, чем упомянутые выше случаи.
Тут двойной факап. И упоминания С++, который находится в авангарде «compiler as a service» и догматическая уверенность в одном избранном случае.
У вас дара в логике.: — семантически отделяет тип. Вы игнорируете сей факт и свободно подменяете семантику: во имя подбития реальности под свою модель.
К тому же, вы взяли какую-то логику и каким-то образом определили её за правильную, а далее исходите из того, что всё что иное — неправильное. Ведь любая другая логика — неправильная.
С таким же успехом можно сказать про ref и про override и прочее. Вы говорите о каком-то примитивном обрубке, а не о каких-то общих правилах.
В общих правилах определяющим является имя, а уже далее что-то там из него следует. Но если имя является определяющим, то на каком основании оно должно быть вначале? Да ни по каким — это догмат.
Начнём с того, что сишный синтаксис создан как f(a, b) {} — изначально все типы были auto(из крестов). Правда там не было вывода типов, а универсальный тип просто был интом.
Всё что слева/справа ничего не значит. При этом в си есть прямое разделение на право и лево. Есть тип, а есть объект. То, что написано справа — относится к объекту, а всё что слева — к его типу.
В примитивных языка такого разделения нет — на то они и примитивные. В том же bosque разделение уже появляется — там есть тот же ref, т.е. то, что относится к самому объекту.
Можно, конечно, делать это делать слева до :, как многие и делают. Но, очевидно, что получается полный треш. Всякие там name?: type.
Правда в Си всё не совсем так. Там тип не может быть массивом, потому что массив — это объект. Так же как типом не может быть функция.
Хотя, конечно, в си есть и тип-функция и тип-массив, но только в рамках тайпдефа. Так же, есть (int[]){} — это логика исходит из того же. По такому же принципу работает using в С++.
Если проще. Объект может переменной — это просто тип. Если мы видим просто тип — это тип какого-то объекта/переменной.
Но, в случае с [] — типом будет массив. Объект будет массивом. А типом указывается тип возврата операции/тора [], аналогично и с () — скобочки уже из объекта делают функцию. А всё остальное к делу отношения не имеет. Тип, который слева — это не тип объекта — это тип возвращаемый (). Потому что свободный тип — это всегда объект(какого-либо значение).
Поэтому си читается следующим образом. void f(); f — это идентификатор/имя. Вы без проблем можете писать void f()[] — функция будет возвращать массив. Тоже самое с [][], вы можете написать int arr[10]() — тоже без проблем.
И это бы всё работало круто, но в си есть фундаментальное разделение. Есть объекты как значения(которые могут быть значениями), а есть которые не могут. Вот [] и () значениями быть не могут.
Таким образом сишный синтаксис и его семантика куда строже и логичнее, нежели упомянутая вами. Где вы как угодно трактуете каждую закорючку.
Описать его можно так. Есть база, которой вы даёте тип. Тип задаётся как справа так и слева. Причём есть два типа типов. Тип самого объекта(массив/переменная(значение)/функция), который пишется справа. И всякие расширения — это слева.
f() — это функция, тип объекта. Слева накидываются всякие свойства, свйоства накидываются ИМЕННО на объект(это упомянутая мною база). f тут уже вообще не при делах.
() — расширяется параметрами. Так же, он возвращает какой-то объект. Тип объекта справа не написан — значит это обычный объект/значение. Этот объект является базой. Ему можно задать тип и всякие там квалификаторы.
* — это тип. Никаких «на» там нет. Это просто упрощение. * — такая же база. Правила те же, но она слева и приоритет у неё меньше. Именно для этого там скобочки — они выделяют новую базу.
И теперь, я думаю, вы сами сможете прочитать bool f(int, string)
База по умолчанию — идентификатор. Идентификатор имеет тип-объект функция. f — это функция, () — имеет семантику «аргументы и „возвращаемое для операции () значение“(по-колхозному возвращает значение)». Читаем аргументы. Аргументы типа инт и строка. Далее эта функция что делает? Возвращает значение(справа ничего нет). Далее, слева могут стоять уточняющие, а именно тип значения и его квалификаторы.
Так же там могут стоять «квалификаторы», которые воздействуют на сам базовый объект.
f — функция с аргументами инт и строка, возвращающая(по-колхозному) значения типа bool.
Т.е. ответа нет и адепт го порвался?
Фантазии брызжущих слюной адептов го.
Я уже отвечал на эту ахинею. Эта ахинея никак не связана с темой и с моим утверждением, т.к. она применима не только к паскаль-стилю.
Т.е. я могу использовать := в любом из стилей. Это просто сахар, костыль. Определяются переменные го не так.
Что за нелепая попытка врать. Читаем мой коммент:
Т.е. брызжущий слюной адепт го врёт, утверждая, что говорил «необходимость мусора в виде ключевого слова типа let, var или auto.», но я приводил это лишь как пример.
Является.
Два символа в if «являются одним, единым оператором». Опять методичка потекла.
Он и есть мусор, т.к. есть уже оператор =. А это другой оператор, который является костылём для решения избыточности паскаль-стиля.
Опять чушь. Именно те, кто рассказывал про «проблему auto» утверждали, что переменную можно объявлять без избыточности.
Я же сообщил, что это неверно и нужен механизм отделения. В ситуации же си-синтаксиса механизм ненужен — он уже есть.
В ситуации же с паскаль-синтаксисом он нужен. Это var/let и прочая фигня. Именно с var сделан ваш го. А далее закостылено := — которая является таким же механизмом, лишней сущностью она повторяет уже существующие функционал.
Вообщем, вы, насколько я погляжу, особо вменяемостью не блещете. Спорить о чём-то с ботами бесполезно, поэтому я вернуть к сити, а именно.
Я отвечал изначально в контексте преимущества паскаль-стиля, т.е. я это опровергал. Теперь вам нужно сообщить — каким образом := относится к паскаль-стилю? Я заранее отвечу — никаким. Новы там можете попытаться что-то придумать.
Есть синтаксис var name type =, базовый. Данный пациент утверждает, что никакой избыточности нет. Но авторы го с ним несогласны.
Именно поэтому вводится var (), это есть ещё со времён паскаля. Потому что все очевидно, что объявление с аннотацией через var — это избыточно. Т.е. пациент спорит с объективной реальностью.
Аналогично с := — это синтаксический сахар, который был добавлен специально для решения проблемы var name auto =.
Т.е. мы имеем как минимум два варианта объявления переменных, но что же там нам сообщал пациент:
Он заявлял, что проблема С++ в том, что синтаксис разный. В целом эти базовая методичка го «делаем что-то одним способом», но.
Как мы видим, что тут эта методичка ломается. Потому что способов как минимум 2(3). А почему? Потому что общий случай избыточен и добавлен специальный сахар для решения проблемы.
Мусор. Вы как бот повторяете один и тот же набор шаблонных фраз.
Основания этим заявлениям.
Есть после имени. До оно, либо после — это ничего не значит.
Нет, вы действительно бот. Какое отношение эти рассуждения имеют к теме? Никакого. Абсолютно неважно что они значит — они значат тоже самое, что и :=, только ещё больше.
Чушь какая. Они имеют отношения к делу и никто их вместо не пишет. Вам лишь сообщили, что подобная логика объявления без типа существовала и существует в си.
Вы опять где-то что-то услышали и начали повторять? Ну расскажите мне про то какой бесполезный статик, либо const, либо volatile. Или это, как обычно, пустой трёп?
Опять же, когда нечего сказать — пиши херню.
Мне надоело с ботом разговаривать.
Хотите поиграть — хорошо, я жду эквивалента кода:
int a;
На го.
Попросту враньё. Инструментов по статическому анализу С++-кода больше и они куда как мощнее и качественнее, чем для го. Никакой С++ парсить ненужно.
К тому же, это враньё ещё и тем, что в го нужны парсеры потому, что язык крайне примитивен и ничего не может. От того и нужнается в кодогене и тысячах костылях, для обхода отсутствия тех же генериков.
Т.е. у вас ничего, кроме лозунгов, нет? Где преимущества, в чём преимущества? Го в сравнении с тем же жаваскриптом/тайпскриптом — пыль. Я уж не говорю про С/С++. Что мне показывает пример го? Да ничего.
Ну то, что ваши тезисы — глупые лозунги я понял уже давно. Вы не на баррикадах и лозунги в данном случае котируются мало.
Примеры. Зачем мне лозунги? Конкретно. Берёте идентичный код и пишите его на го и на С++.
Опять лозунги?
Вы ведь ничего не знаете. Функция объявляется так же.
У вас явно лозунги плывут. Функции в си записывается как int(foo)(); Указатель записывается как int(* foo)(); То, что вы этого не знаете — это проблему. Узнайте/спросите перед тем, как делать далеко идущие заявления.
Опять лозунги. Приведите пример.
Это настолько нелепые заявления. Синтаксис го не может и 10% того, что может синтаксис си в С++, в том же C#. Зачем сравнивать несравнимое?
Это примерно как рассказывать, что у мышки 3 кнопки, а у клавиатуры 100. Вот ведь какая клавиатура плохая — кнопок много. Авторы мышки стремились сделать такое кол-во кнопок(малое) и они добились этого.
Все ваши рассуждения — пустые общие слова, которые ничего не значат.
Она извращённая лишь потому, что вы где-то это услышали? Сильная аргументация.
И да, у вас опять лозунг потёк. Покажите мне эквивалент С++-лямбды на го, либо на другом языке.
Нельзя. := — это синтаксический мусор, который, к тому же, писать сложнее нежели =, либо auto.
К тому же, как я уже говорил — мы либо вводим :=/=, либо мы имеем не только := в качестве синтаксического мусора, но и аннотацию при которой := избыточно.
Это так же неверно, т.к. двоеточие не имеет никакого отношения к подходу.
Я больше скажу — в си вообще аннотация типа ненужна. Она используется только для в одном случае — определение. Да и то нужен просто какой-то флаг для выражения намерения. Подойдёт вообще что угодно. const/auto/register. Всё это уже придумано и давно. Го просто взял эту логику из си.
Кому, кроме студентов, интересна сложность парсинга? Язык должен быть мощным и удобным, а насколько его сложно парсить — никому не интересно.
Пустой лозунг, который я уже опровергал выше.
Опять лозунг. Хорошо оно идёт — дальше что?
Парсинг никому не интересен. Чем это использование более адекватно? Что вообще это значит. Опять какой-то лозунг без примеров/объяснений.
Опять же, в чём заключается пытка?
К тому же, := — является таким же кейвордом, о котором я говорил. И абсолютно неважно в каком он будет виде. Т.е. мой тезис это никак не опровергает.
К тому же, это вообще находится за рамками контекста т.к. контекстом является а) синтаксис принятый в обсуждаемом языке, б) синтаксис принятый в си.
Так же, := — избыточен для ситуаций, где тип не выводится, а задаётся. Вам придётся либо использовать избыточность, либо вводить два типа операторов, что опять же — избыточность и синтаксический мусор.
К тому же, это локальные го-заморочки не присущи ни паскалю, ни всему тому, что используется его стиль.
А так же, самое важное — это вообще никак не зависит от стиля. Это работает в любом случае. Т.е. смысла приводить это в контексте разделения стилей нет — т.к. это не относится к одному из — это относится к обоим.
Дак вы должны это сделать — как я буду читать непонятно какие, придуманные вами, символы?
Как нам разница — как и кто читает? К тому же нужно отличать чтение от понимания. Читать можно как угодно. К тому же, прочитайте мне 123.123. Прочитай мне a + b * (c + d).
Я могу читать как угодно, как и любой другой человек. И все именно так и читают. Читают таблицы сверху вниз, либо таблицы нужно запретить? Ищут ключевые слова в текста. Запоминают контекст.
Указатель — это тип *, T — это тип возврата операции разыменования. Слева всегда стоит конечный тип. Сишные определения читаются как математические выражения. Вот паста, где я разбирал «как читать».
Лозунги такие лозунги.
Я вам привёл примеры — почитайте их. Не нужно путать чтение и интерпретирование. Читать можно что угодно и как угодно, но понимать вы будите так как нужно.
Пустые заявления. Да и расскажите это арабам.
Вы ничего не знаете о си и эта формулировка — полная чушь. Ну и я жду срывов покровов на тему number[], жду чтения () => {}. Ваши рассуждения глупы и догматичны. Во-первых указатель ни на какие переменные не указывает. На этом уже можно закончить и признать вашу несостоятельность, полную.
Вы попросту хейтер, который придумал какую-то чушь и ему кажется, что его объяснения что-то объясняют, но нет. Хейтер просто услышал где-то про «паскаль читается, а си нет» и начал выдумывать чушь. Назвав набором слов всё, начиная от математики заканчивая каким-нибудь тайпскриптом.
Это и есть набор слов. Вы пытаетесь рассуждать на тему, в которой ничего не понимаете, приводя идиотские примеры(это даже не примеры, а полный треш). Я отказываю даже читать этот набор слов пока там не будет нормальных примеров с объяснениями — что вообще этот набор слов значит и как он следует из тех же сишных определений.
Это какие-то попытки подменить изначальный тезис. Был пример со sturct — я показал, что в этом языке используется такая же форма определения объектов. Она используется везде, в том же тайпскрипте.
Где тут: struct name — стоит слева тип? Нигде.
Начнём с того, что сишный sturct под неё подходит, а говорилось именно о нём. Так же никакое положение в таблице не обосновывается, никак. Т.е. на каком основании "(id: int, data: string)" является «domain», а bool не является. К тому же, ваша табличка игнорирует override method, ref env.
Ну и на самый главный вопрос нет ответа. Почему? Можно нарисовать какую угодно табличку, но вопрос заключается в том — почему так должно быть? Зачем строить свои рассуждения на догматах?
Скорее в древних блокнотах. Современный редактор умеет в семантическую подсветку. А подсветка уровня кейвордов — это про древний блокнот.
Соответственно — function является лишним синтаксическим шумом, т.е. редактор умеет красить функции в уникальный цвет. И современно без разницы какие они.
Почему? К тому же везде и всюду сделано аналогично и здесь:
function updateentity Foo {
И так далее.
Распарсить это решительно невозможно. Это какой-то набор слов. Напишите что-то более адекватное типа «в крестах так: бла-бла, а нужно так: бла-бла».