- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
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.08.2021 17:48 # 0
ASD_77 14.08.2021 17:49 # 0
j123123 14.08.2021 18:11 # +2
Видимо это "структура".
> let v: int | undefined;
Видимо это "юнион".
И че? В чем тут проблема? Тут опять говноRTTI нужно, да?
3.14159265 14.08.2021 18:18 # +1
> Видимо это "юнион"
Больше похоже на интовый указатель.
Может быть undefined (NULL), а может указывать на число.
j123123 14.08.2021 18:26 # +1
Ну вот эта херня с палочкой это именно union. https://www.educba.com/typescript-union-types/
Вероятно, есть такой тип "undefined", единственное значение которого - "undefined". Или может это просто тип сам по себе, без значений и возможности чего-то там хранить. Типа "let v: int | undefined;" это значит что "там или int хуйня с каким-то значением, или undefined где нет нихуя". Такая вот скриптуха анскильная
j123123 14.08.2021 18:34 # +1
ru66oH4uk 14.08.2021 18:51 # 0
это кортеж / тупла. Первый элемент int (в TS нет такого типа, хз откуда он его высрал), второй boolean
>Видимо это "юнион".
так точно
j123123 14.08.2021 18:52 # 0
И чем "кортеж / тупла" отличается от структур в C?
ru66oH4uk 14.08.2021 18:53 # 0
j123123 14.08.2021 18:54 # 0
ru66oH4uk 14.08.2021 18:56 # 0
В целом это одно и тоже, конечно: некая совокупность данных гетерогенная.
Кортеж наверное чуть ма-те-ма-тичнее
j123123 14.08.2021 19:01 # 0
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
ru66oH4uk 14.08.2021 19:05 # 0
У кого жемчуг мелок, у кого суп жидок
Кстати, как с зависимыми типами дела у сишки?
3.14159265 14.08.2021 19:08 # 0
У кого стул жидок.
j123123 14.08.2021 19:16 # +1
По сравнению с говном с параши, у полупротухшей колбасы из мяса крыс прекрасный вкус
ru66oH4uk 14.08.2021 19:19 # +1
3EHuTHblu_nemyx 14.08.2021 20:03 # 0
Chupacabramiamor 14.08.2021 20:04 # 0
ru66oH4uk 14.08.2021 20:22 # 0
COPOKA 14.08.2021 21:43 # 0
P.S. А в «TCL», кажется, и «нескалярное» значение — тоже строка.
ru66oH4uk 14.08.2021 21:46 # +2
>любое «скалярное» значение — это строка
В таких языках обычно есть отдельный оператор для сравнения строк, потому что "==" может не сработать, и совсем не по той причине, по какой он не работает в си и жабе
PolinaAksenova 14.08.2021 21:49 # +1
Странный какой язык. Для питухов, няверное.
COPOKA 14.08.2021 22:19 # 0
COPOKA 14.08.2021 22:04 # 0
Кажется, я его знаю. Это тот, в котором ломаешь голову, почему только старшие 53 значащих бита целого числа сохраняются, а в младших мусор? И из-за которого «Твиттер» в своём API возвращает айдишник пользователя два раза: один раз числом, второй раз — строкой на случай, если в числовом представлении младшие биты затёрлись?
3.14159265 14.08.2021 22:27 # 0
Если речь о жс, то там давно уже не всё так просто.
Питух, питухом а Uint32Array плав. питухом не пахнет.
> только старшие 53 значащих бита
1<<32 == 1
1<<31 == -2147483648
ru66oH4uk 14.08.2021 22:32 # 0
Семантически это так. Что там JIT делает мы не знаем, это implementation details. Так-то и в перле число не обязано строкой храниться на самом-то деле.
>Uint32Array
Это объект же, причем тут числа?
3.14159265 14.08.2021 22:37 # +1
Это был намёк на 32-битные целые.
Если бы там были плавающие, то сдвиг бы работал совершенно иначе.
>Что там JIT делает мы не знаем, это implementation details
Зато мы знаем что пишут в Стандарте, а там целая секция посвящена целочисленным преобразованиям и операциям:
https://262.ecma-international.org/5.1/#sec-9.5
ru66oH4uk 14.08.2021 22:40 # 0
А про тип там чётко сказано
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
3.14159265 14.08.2021 22:41 # +2
Зачем они сделали 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.
Там на самом деле куча мест где есть целые: битовая арифметика, чары, индексы массивов.
3.14159265 14.08.2021 22:46 # 0
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
ru66oH4uk 14.08.2021 22:52 # 0
но это не значит, что 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
3.14159265 14.08.2021 22:57 # 0
ru66oH4uk 14.08.2021 23:05 # +1
Number и BigInt нельзя смешивать в операциях — они должны быть приведены к тому же типу.
[/quote]
какой пиздец ))
Впрочем, принято: кроме питуха есть еще и bigint
3.14159265 14.08.2021 23:18 # +1
Но если подумать: явные преобразования лучше неявных, да и без длинных целых это был язык-инвалид.
Потому новшества ECMAScript 2020 у меня практически не вызывают неприятия. Всего пару фич, и в целом безобидных. На фоне пиздеца что они натворили в ES6.
1024-- должно быть радуется ?? и ?.
guest6 14.08.2021 23:26 # 0
3.14159265 14.08.2021 23:50 # 0
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 работают, восьмишковый багор исправили, битовые операции тоже в порядке.
И кольцо чисел выходит замкнутое.
Chupacabramiamor 15.08.2021 00:34 # 0
Hacpy 15.08.2021 09:19 # 0
j123123 14.08.2021 20:06 # +1
typeof()
> Значит ли это, что сишка это говно из параши?
Да. И кресты кстати тоже говно. https://govnokod.ru/23287#comment389547
ru66oH4uk 14.08.2021 20:07 # 0
COPOKA 14.08.2021 20:44 # 0
guest6 14.08.2021 20:45 # 0
COPOKA 14.08.2021 21:19 # +1
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(), ибо если он его не умеет - этот конпелятор не может проверять типы - а это требование стандарта. Поэтмоу какт олько гцц появился, да и любой другйо вменяемый конпелятор - в нём появился тайпов.»
Итого из слов «Царя» следует, что любой нормальный компилятор должен поддерживать гэцэцизмы.
guest6 14.08.2021 21:22 # 0
COPOKA 14.08.2021 21:30 # +1
«На одной архитектуре у УБ обычно есть одна единственная разумная реализация - её придерживаются все нормальный конпеляторы. Остальные конпеляторы - говно, и за Си-конпелятор не считается.
В мире сейчас один единственный Си-конпелятор - ГЦЦ. Сейчас он является почти эталонной реализацией сишки и всех фич. Остальные нормальные конпеляторы, аля icc, питух-шланг берут в основу своего поведения - поведение гцц. В 80% им его даже не надо брать, ибо в нормальных реализациях поведение одинакого.»
https://govnokod.ru/13323#comment186862
https://govnokod.xyz/_13323/#comment-185467
Поискал ещё его комментарии. Выяснил, что «msvc», «icc» и «шланг» — говно, потому что не на 100% совместимы с «гцц».
3.14159265 14.08.2021 21:46 # +1
>>УБ
>>разумная реализация
Интересно как разумно реализовать такое?
ptr++ = *++ptr + *ptr++;
3.14159265 14.08.2021 21:55 # 0
Не, ну он как обычно прав.
3.14159265 14.08.2021 20:09 # +1
ru66oH4uk 14.08.2021 20:22 # 0
3.14159265 14.08.2021 20:25 # +1
ASD_77 14.08.2021 21:19 # 0
COPOKA 14.08.2021 22:13 # 0
PolinaAksenova 14.08.2021 22:16 # 0
3.14159265 14.08.2021 22:24 # +1
guest6 14.08.2021 22:16 # +1
3.14159265 14.08.2021 22:22 # +1
И что мы имеем - мы имеем бездарных животных, которые нихрена о структурах данных и вообще о представлении данных не знают, а заучили пару примитивных конструкций, выдавая это за "структуры данных".
ru66oH4uk 14.08.2021 22:36 # +1
Вот ты знаешь массивы? Значит ли это, что ты автоматически знаешь и префиксное дерево, например?
j123123 14.08.2021 19:18 # 0
На том уровне абстракций завипы не нужны. Но это можно решить, например я не так давно скидывал про такую хуйню в https://govnokod.ru/27541
ru66oH4uk 14.08.2021 19:20 # +1
j123123 14.08.2021 19:25 # 0
ASD_77 14.08.2021 19:06 # +1
ru66oH4uk 14.08.2021 19:06 # 0
Это literal type получается. Используется, втч, для эмуляции паттерн матчинга
3.14159265 14.08.2021 18:16 # 0
Забавное описание nullаble.
Это и в оригинальном ts так можно писать?
ru66oH4uk 14.08.2021 18:51 # 0
В самом TS так писать можно, конечно
ASD_77 14.08.2021 18:52 # 0
3.14159265 14.08.2021 18:54 # 0
> int | undefined
Потому я и спрашиваю, в ts тоже так можно?
ASD_77 14.08.2021 19:19 # 0
3.14159265 14.08.2021 19:51 # 0
ru66oH4uk 14.08.2021 19:53 # 0
https://stackoverflow.com/questions/18808226/why-is-typeof-null-object
Это обсёр.
3.14159265 14.08.2021 20:07 # +1
Лулз в том что эта питушня появилась из-за тех же проблем что и у ОПа.
Так вот, я хотел указать что если Сишнику вдруг не хватает битов (см. спор 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.
1024-- 14.08.2021 20:10 # 0
А тут что плохого с typeof? void просто зря сделали.
ASD_77 14.08.2021 21:22 # 0
ASD_77 14.08.2021 18:51 # 0
j123123 14.08.2021 18:53 # 0
ASD_77 14.08.2021 19:10 # 0
ASD_77 14.08.2021 19:13 # 0
ru66oH4uk 14.08.2021 19:15 # 0
А вот где он будет хранить тип это другой вопрос
ASD_77 14.08.2021 19:21 # 0
j123123 14.08.2021 19:24 # 0
ASD_77 14.08.2021 19:30 # 0
Chupacabramiamor 14.08.2021 19:30 # −2
j123123 14.08.2021 19:31 # 0
Chupacabramiamor 14.08.2021 19:31 # −2
guest6 14.08.2021 19:32 # +1
Chupacabramiamor 14.08.2021 19:33 # −2
guest6 14.08.2021 19:34 # 0
Chupacabramiamor 14.08.2021 19:47 # 0
j123123 14.08.2021 19:23 # 0
Обычный сишный юнион. А как хранить тип - можно в энуме, можно в компилтайме все знать. Много вариантов
ASD_77 14.08.2021 19:30 # 0
Chupacabramiamor 14.08.2021 19:33 # −2
j123123 14.08.2021 19:34 # 0
Chupacabramiamor 14.08.2021 19:35 # 0
ASD_77 14.08.2021 19:38 # 0
Chupacabramiamor 14.08.2021 19:39 # 0
1024-- 14.08.2021 20:14 # 0
Можно впетушить тип вида int | array<int> | tuple<int,int,array<double>> (псевдокод)?
ru66oH4uk 14.08.2021 20:15 # 0
PolinaAksenova 14.08.2021 20:27 # −3
Chupacabramiamor 14.08.2021 19:29 # −3