x << y === x >> -y
6.1.6.2.10 BigInt::signedRightShift ( x, y )
The abstract operation BigInt::signedRightShift takes arguments x (a BigInt) and y (a BigInt). It performs the following steps when called:
1. Return BigInt::leftShift(x, -y).
6.1.6.2.9 BigInt::leftShift ( x, y )
The abstract operation BigInt::leftShift takes arguments x (a BigInt) and y (a BigInt). It performs the following steps when called:
1. If y < 0ℤ, then
a. Return the BigInt value that represents ℝ(x) / 2-y, rounding down to the nearest integer, including for negative numbers.
2. Return the BigInt value that represents ℝ(x) × 2y.
NOTE
Semantics here should be equivalent to a bitwise shift, treating the BigInt as an infinite length string of binary two's complement digits.
(1 << 0).toString(2) // "1"
(1 << 1).toString(2) // "10"
// ...
(1 << 30).toString(2) // "1000000000000000000000000000000"
(1 << 31).toString(2) // "-10000000000000000000000000000000"
(1 << 32).toString(2) // "1" (как при 0)
(1 << 33).toString(2) // "10" (как при 1)
// .. .
(1 << Number.MAX_SAFE_INTEGER).toString(2) // // "-10000000000000000000000000000000" (как при 31)
но где это описано в спеках, и описано ли - сходу не нашел. shiftValue & 0x1F
, из-за чего -1 превращается в 31. А поскольку при значении 31 все биты (кроме последнего, который отвечает за чётность, если можно так сказать), то остальные биты "сгорают" и в результате имеем либо 0 (для чётных чисел), либо -2147483648 (для нечётных). 0 true
- это вызов c(0 < 14)
1 true
- это вызов самой внешней функции с()
true
- это возвращаемое значение самой внешней функцией с()
0 < 14
, затем результат передается в функцию.true
.c(0 < 14) || c(0 > 90 === 0 >= 14) && c(0 <= 90)
имеет вид TRUE || c(0 > 90 === 0 >= 14) && c(0 <= 90)
. Данное выражение однозначно даст в результате true
и поэтому остальные условия не проверяются (для этой стратегии вычислений булевых выражений есть какой-то специальный термин, но я его не помню), и, соответственно, функции не выполняются. true
) передается во внешнюю функцию и она выполняется, делая второй вывод в консоль. Позволяют ли нынешние популярные реализации серверов (Apache, nginx, Google Web Server и другие) поступать не так, как следует?
Упоминаются ли данные "следует" и "должен" в стандартах HTTP, либо данное существуют только на уровне соглашения между разработчиками?
Что будет, если отвечать не как следует, кроме того, что работа скорее всего станет некорректной, если клиент опирается именно на то, как сервер должен отвечать, а не на то, как он отвечает? Например, если сервер использует вместо стандартных заголовков нестандартные?
Можно ли использовать собственное название метода, которое может обработать сервер или же список методов всё таки ограничен, перечисленными в спецификациях HTTP, и выбирать следует из них?
requests
можно выкинуть, раз избавляешься от лишнего.null
(что правильнее, как по мне).userNames
может оказаться больше чем десяток записей - лучше их запросы разбить, в зависимости от возможностей сервера и канала.