Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+2
type int = 1;
function main() {
let result: [value: int, done: boolean];
let v: int | undefined;
v = 1;
result = [v, false];
print(result[0], result[1]);
assert(result[0] == 1);
assert(result[1] == false);
}опа. новый говнокодец подоспел. а кто знает какая проблема решалась в данном коде?
Запостил: 
ASD_77,
14 Августа 2021
Follow us!
Видимо это "структура".
> let v: int | undefined;
Видимо это "юнион".
И че? В чем тут проблема? Тут опять говноRTTI нужно, да?
> Видимо это "юнион"
Больше похоже на интовый указатель.
Может быть undefined (NULL), а может указывать на число.
Ну вот эта херня с палочкой это именно union. https://www.educba.com/typescript-union-types/
Вероятно, есть такой тип "undefined", единственное значение которого - "undefined". Или может это просто тип сам по себе, без значений и возможности чего-то там хранить. Типа "let v: int | undefined;" это значит что "там или int хуйня с каким-то значением, или undefined где нет нихуя". Такая вот скриптуха анскильная
это кортеж / тупла. Первый элемент int (в TS нет такого типа, хз откуда он его высрал), второй boolean
>Видимо это "юнион".
так точно
И чем "кортеж / тупла" отличается от структур в C?
В целом это одно и тоже, конечно: некая совокупность данных гетерогенная.
Кортеж наверное чуть ма-те-ма-тичнее
https://stackoverflow.com/questions/66119146/typescript-how-to-make-generic-type-to-infer-inside-a-function
> As mentioned in the comments, TypeScript doesn't really have support for dependent types, especially not when it comes to type checking the implementation of a function whose call signature implies such a dependency
У кого жемчуг мелок, у кого суп жидок
Кстати, как с зависимыми типами дела у сишки?
У кого стул жидок.
По сравнению с говном с параши, у полупротухшей колбасы из мяса крыс прекрасный вкус
P.S. А в «TCL», кажется, и «нескалярное» значение — тоже строка.
>любое «скалярное» значение — это строка
В таких языках обычно есть отдельный оператор для сравнения строк, потому что "==" может не сработать, и совсем не по той причине, по какой он не работает в си и жабе
Странный какой язык. Для питухов, няверное.
Кажется, я его знаю. Это тот, в котором ломаешь голову, почему только старшие 53 значащих бита целого числа сохраняются, а в младших мусор? И из-за которого «Твиттер» в своём API возвращает айдишник пользователя два раза: один раз числом, второй раз — строкой на случай, если в числовом представлении младшие биты затёрлись?
Если речь о жс, то там давно уже не всё так просто.
Питух, питухом а Uint32Array плав. питухом не пахнет.
> только старшие 53 значащих бита
1<<32 == 1
1<<31 == -2147483648
Семантически это так. Что там JIT делает мы не знаем, это implementation details. Так-то и в перле число не обязано строкой храниться на самом-то деле.
>Uint32Array
Это объект же, причем тут числа?
Это был намёк на 32-битные целые.
Если бы там были плавающие, то сдвиг бы работал совершенно иначе.
>Что там JIT делает мы не знаем, это implementation details
Зато мы знаем что пишут в Стандарте, а там целая секция посвящена целочисленным преобразованиям и операциям:
https://262.ecma-international.org/5.1/#sec-9.5
А про тип там чётко сказано
https://262.ecma-international.org/5.1/#sec-8.5
he Number type has exactly 18437736874454810627 (that is, 264−253+3) values, representing the double-precision 64-bit format IEEE 754 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, except that the 9007199254740990 (that is, 253−2) distinct “Not-a-Number” values of the IEEE Standard are represented in ECMAScript as a single special NaN value
Зачем они сделали parseInt (string , radix) и parseFloat (string)?
The parseInt function produces an integer value dictated by interpretation of the contents of the string argument according to the specified radix.
Там на самом деле куча мест где есть целые: битовая арифметика, чары, индексы массивов.
The Int8Array typed array represents an array of twos-complement 8-bit signed integers. The contents are initialized to 0. Once established, you can reference elements in the array using the object's methods, or using standard array index syntax (that is, using bracket notation).
> любое _числовое_ значение это питух
Там давно и вполне легально завезены целые инты.
var x=Int8Array.of(128)
x[0]
128
++x[0]
-127
x[0]/=3 //возвращает -42.3333333333, однако в x[0]==-42
но это не значит, что JS появился тип "petuh"
>var x=Int8Array.of(128)
А что же такое number? Может быть int?
Нет:
Number type has exactly 18437736874454810627 (that is, 264−253+3) values, representing the double-precision 64-bit format IEEE 754 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, except that the 9007199254740990 (that is, 253−2) distinct “Not-a-Number” values of the IEEE Standard are represented in ECMAScript as a single special NaN value
Number и BigInt нельзя смешивать в операциях — они должны быть приведены к тому же типу.
[/quote]
какой пиздец ))
Впрочем, принято: кроме питуха есть еще и bigint
Но если подумать: явные преобразования лучше неявных, да и без длинных целых это был язык-инвалид.
Потому новшества ECMAScript 2020 у меня практически не вызывают неприятия. Всего пару фич, и в целом безобидных. На фоне пиздеца что они натворили в ES6.
1024-- должно быть радуется ?? и ?.
Literals for BigInts are similar to Number literals, but followed by n. They can be written with binary, octal or hexadecimal notation, e.g., 0x100n. Legacy octal syntax (0640) is not allowed, only new-style (0o064n).
The choice of BigInt comes from an attempt to preserve user intuition about the lack of compatibility of BigInt with things that are currently based on Numbers. Because implicit coercions lead to TypeErrors, the guidance is that existing users of Numbers should stay with Numbers if it works for the application, and only large usages need to upgrade to BigInt
A key design decision is to disallow mixed operations between BigInts and Numbers. The driving factor: Any implicit coercions would lose information.
When adding two values of different numeric types, between large integers and floating point numbers, the mathematical value of the result may be outside of the domain of either. For example, (2n**53n + 1n) + 0.5 has a value which cannot be accurately represented in either range. Floating point arithmetic is not the exact mathematical value, but at least it is well-defined by IEEE 754. The entire aim of introducing BigInt is, on the other hand, to make a way to preserve integer precision of larger values.
>So, if mixed-precision were allowed, an innocent calculation such as 2n ** 53n + 1 would produce the float 2**53--defeating the core functionality of this feature.
https://github.com/tc39/proposal-bigint/blob/master/ADVANCED.md
На самом деле я даже не могу найти где бы они обосрались: сравнения bigint и number работают, восьмишковый багор исправили, битовые операции тоже в порядке.
И кольцо чисел выходит замкнутое.
typeof()
> Значит ли это, что сишка это говно из параши?
Да. И кресты кстати тоже говно. https://govnokod.ru/23287#comment389547
https://govnokod.xyz/_13162/#comment-179312
https://govnokod.ru/13162#comment180645
https://govnokod.xyz/_13162/#comment-179270
https://govnokod.ru/13162#comment180653
https://govnokod.xyz/_13162/#comment-179272
https://govnokod.ru/13162#comment180656
https://govnokod.xyz/_13162/#comment-179273
И самое главное:
https://govnokod.ru/13180#comment181058
https://govnokod.xyz/_13180/#comment-180012
«Контрольные: Любой конпелятор умеет typeof(), ибо если он его не умеет - этот конпелятор не может проверять типы - а это требование стандарта. Поэтмоу какт олько гцц появился, да и любой другйо вменяемый конпелятор - в нём появился тайпов.»
Итого из слов «Царя» следует, что любой нормальный компилятор должен поддерживать гэцэцизмы.
«На одной архитектуре у УБ обычно есть одна единственная разумная реализация - её придерживаются все нормальный конпеляторы. Остальные конпеляторы - говно, и за Си-конпелятор не считается.
В мире сейчас один единственный Си-конпелятор - ГЦЦ. Сейчас он является почти эталонной реализацией сишки и всех фич. Остальные нормальные конпеляторы, аля icc, питух-шланг берут в основу своего поведения - поведение гцц. В 80% им его даже не надо брать, ибо в нормальных реализациях поведение одинакого.»
https://govnokod.ru/13323#comment186862
https://govnokod.xyz/_13323/#comment-185467
Поискал ещё его комментарии. Выяснил, что «msvc», «icc» и «шланг» — говно, потому что не на 100% совместимы с «гцц».
>>УБ
>>разумная реализация
Интересно как разумно реализовать такое?
ptr++ = *++ptr + *ptr++;
Не, ну он как обычно прав.
И что мы имеем - мы имеем бездарных животных, которые нихрена о структурах данных и вообще о представлении данных не знают, а заучили пару примитивных конструкций, выдавая это за "структуры данных".
Вот ты знаешь массивы? Значит ли это, что ты автоматически знаешь и префиксное дерево, например?
На том уровне абстракций завипы не нужны. Но это можно решить, например я не так давно скидывал про такую хуйню в https://govnokod.ru/27541
Это literal type получается. Используется, втч, для эмуляции паттерн матчинга
Забавное описание nullаble.
Это и в оригинальном ts так можно писать?
В самом TS так писать можно, конечно
> int | undefined
Потому я и спрашиваю, в ts тоже так можно?
https://stackoverflow.com/questions/18808226/why-is-typeof-null-object
Это обсёр.
Лулз в том что эта питушня появилась из-за тех же проблем что и у ОПа.
Так вот, я хотел указать что если Сишнику вдруг не хватает битов (см. спор j123123 и ASD_77) то он может хранить флаг и в младших битах адреса
I take a look at the C code of typeof to better explain why typeof null results in 'object'.
In JavaScript, typeof null is 'object', which incorrectly suggests that null is an object (it isn’t, it’s a primitive value, consult my blog post on categorizing values for details). This is a bug and one that unfortunately can’t be fixed, because it would break existing code. Let’s explore the history of this bug.
The “typeof null” bug is a remnant from the first version of JavaScript. In this version, values were stored in 32 bit units, which consisted of a small type tag (1–3 bits) and the actual data of the value. The type tags were stored in the lower bits of the units. There were five of them:
000: object. The data is a reference to an object.
1: int. The data is a 31 bit signed integer.
010: double. The data is a reference to a double floating point number.
100: string. The data is a reference to a string.
110: boolean. The data is a boolean.
That is, the lowest bit was either one, then the type tag was only one bit long. Or it was zero, then the type tag was three bits in length, providing two additional bits, for four types.
Two values were special:
undefined (JSVAL_VOID) was the integer −230 (a number outside the integer range).
null (JSVAL_NULL) was the machine code NULL pointer. Or: an object type tag plus a reference that is zero.
It should now be obvious why typeof thought that null was an object: it examined its type tag and the type tag said “object”. The following is the engine’s code for typeof.
А тут что плохого с typeof? void просто зря сделали.
А вот где он будет хранить тип это другой вопрос
Обычный сишный юнион. А как хранить тип - можно в энуме, можно в компилтайме все знать. Много вариантов
Можно впетушить тип вида int | array<int> | tuple<int,int,array<double>> (псевдокод)?