Не так давно JavaScript похвастался новым примитивным типом данных BigInt для работы с числами произвольной точности. Про мотивацию и варианты использования уже рассказан/переведен необходимый минимум информации. А мне бы хотелось обратить чуть больше внимания на превнесенную локальную «явность» в приведении типов и неожиданный TypeError. Будем ругать или поймем и простим (опять)?
Неявное становится явным?
В языке, где неявное преобразование типов давно привыклось, стало мемом почти любой конференции и уже мало кого удивляет такими замысловатостями, как:
1 + {}; // '1[object Object]'
1 + [[0]]; // '10'
1 + new Date; // '1Fri Feb 08 2019 00:32:57 GMT+0300 (Москва, стандартное время)'
1 - new Date; // -1549616425060
...
Мы неожиданно получаем TypeError, пытаясь сложить два, казалось бы, ЧИСЛА:
1 + 1n; // TypeError: Cannot mix BigInt and other types, use explicit conversions
И если предыдущий опыт неявностей не привел к нервному срыву при изучении языка, то тут появляется второй шанс сорваться и выбросить учебник по ECMA и уйти в какую-нибудь Java.
Далее язык продолжает «троллировать» js-разработчиков:
1n + '1'; // '11'
Ах да, не забываем про унарный оператор +:
+1n; // TypeError: Cannot convert a BigInt value to a number
Number(1n); // 1
Если коротко, то мы не можем смешивать в операциях BigInt и Number. Как следствие, не рекомендуется использовать «большие целые», если 2^53-1 (MAX_SAFE_INTEGER) нам достаточно в наших целях.
Ключевое решение
Да, это стало главным решением настоящего нововведения. Если забыть, что это JavaScript, то все так-то логично: эти неявные преобразования способствуют потере информации.
Когда мы складываем два значения разных числовых типов (большие целые и числа с плавающей точкой), математическое значение результата может оказаться вне их области возможных значений. Например, значение выражения (2n ** 53n + 1n) + 0.5 не может быть точно представлено ни одним из этих типов. Это уже не целое, а вещественное число, но его точность формат float64 уже не гарантирует:
2n ** 53n + 1n; // 9007199254740993n
Number(2n ** 53n + 1n) + 0.5; // 9007199254740992
В большинстве динамических языков, где представлены типы и для целых чисел (integer), и для чисел с плавающей точкой (float), первые записываются как 1, а вторые — 1.0. Тем самым, при арифметических операциях по наличию десятичного разделителя в операнде можно сделать вывод о приемлемости точности float в вычислениях. Но JavaScript — не из их числа, и 1 — есть float! А это значит, что вычисление 2n ** 53n + 1 вернет float 2^53. Что, в свою очередь, ломает ключевую функциональность BigInt:
2 ** 53 === 2 ** 53 + 1; // true
Ну и о реализации «числовой башни» говорить тоже не приходится, так как взять существующий number как общий числовой тип данных не получится (по той же причине).
И чтобы избежать эту проблему, неявное приведение между Number и BigInt в операциях оказалось под запретом. Как итог, «большое целое» не получится безопасно прокинуть в какую-либо функцию JavaScript или Web API, где ожидается обычный number. Необходимо явно выбирать один из двух типов применением Number() или BigInt().
Кроме того, для операций со смешанными типами встречается объяснение о сложной реализации или потере производительности, что довольно частое явление для компромиссных нововведений языка.
Конечно, это распространяется на неявные численные преобразования с другими примитивами:
1 + true; // 2
1n + true; // TypeError
1 + null; // 1
1n + null; // TypeError
Но следующие (уже) конкатенации будут работать, так как ожидаемый результат — это строка:
1n + [0]; // '10'
1n + {}; // '1[object Object]'
1n + (_ => 1); // '1_ => 1'
Еще исключение — в виде операторов сравнения (как <, > и ==) между Number и BigInt. Здесь тоже нет потери точности, так как результат — это булево.
Ладно, если вспомнить предыдущий новый тип данных Symbol, то TypeError уже не кажется таким радикальным дополнением?
Symbol() + 1; // TypeError: Cannot convert a Symbol value to a number
И да, но нет. Ведь концептуально symbol — совершенно не число, а целое — очень даже:
- Крайне мало вероятно, что symbol попадет в такую ситуацию. Тем не менее, подобное — очень подозрительно и TypeError здесь вполне уместен.
- Крайне вероятно и обычно, что «большое целое» в операциях окажется одним из операндов, когда на самом деле ничего страшного нет.
Унарный оператор + же бросает исключение из-за проблемы совместимости с asm.js, где ожидается Number. Унарный плюс не может работать с BigInt аналогично Number, так как в этом случае предыдущий asm.js-код станет неоднозначным.
Альтернативное предложение
Несмотря на относительную простоту и «чистоту» внедрения BigInt, Axel Rauschmeyer подчеркивает недостаток нововведения. А именно, его лишь частичную обратную совместимость с существующим Number и вытекающее:
Use Numbers for up to 53-bit ints. Use Integers if you need more bits
В качестве альтернативы он предложил следующее.
Пусть Number станет супертипом для новых Int и Double:
- typeof 123.0 === 'number', а Number.isDouble(123.0) === true
- typeof 123 === 'number', а Number.isInt(123) === true
C новыми функциями для преобразований Number.asInt() и Number.asDouble(). И, конечно, с перегрузкой операторов и нужными приведениями:
- Int × Double = Double (с приведением)
- Double × Int = Double (с приведением)
- Double × Double = Double
- Int × Int = Int (все операторы, кроме деления)
Интересно, что в упрощенной версии это предложение обходится (сначала) без добавления новых типов в язык. Вместо этого расширяется определение The Number Type: в дополнение ко всем возможным значениям 64-битных чисел двойной точности (IEEE 754-2008) number теперь включает и все целые числа. Следствием, «неточное число» 123.0 и «точное число» 123 — это отдельные числа единого типа Number.
Выглядит очень знакомо и разумно. Однако, это серьезный апгрейд существующего number, который с бОльшей долей вероятности способен «сломать веб» и его инструменты:
- Появляется различие между 1 и 1.0, которого не было до этого. Существующий код использует их взаимозаменяемо, что после апгрейда может привести к путанице (в отличие от языков, где это различие присутствовало изначально).
- Возникает эффект, когда 1 === 1.0 (предполагается апгрейдом), и в то же время Number.isDouble(1) !== Number.isDouble(1.0): опять таки, такое себе.
- «Особенность» равенства 2^53 и 2^53+1 пропадает, что сломает полагающийся на это код.
- Та же проблема совместимости с asm.js и прочее.
Поэтому в итоге мы имеем компромиссное решение в виде нового отдельного типа данных. Просто стоит подчеркнуть, что иной вариант тоже рассматривался и обсуждался.
Когда сидишь на двух стульях
Собственно, комментарий комитета начинается словами:
Find a balance between maintaining user intuition and preserving precision
С одной стороны, хотелось добавить наконец что-то «точное» в язык. А с другой стороны, сохранить его уже привычное для многих разработчиков поведение.
Просто так это «точное» добавить не получится, потому что нельзя ломать: математику, эргономику языка, asm.js, возможность дальнейшего расширения системы типов, производительность и, в конце концов, сам веб! И ломать это все нельзя одновременно, что и приводит к подобному.
А еще ломать нельзя интуицию пользователей языка, о чем, конечно, тоже горячо шел разговор. Правда, получилось ли?
Автор: cerberus_ab
