<p>I do not know of any languages that support this idea but I just thought that since numbers are just bits, why should we not be able to access those bits directly? In most languages such as C or C++, to manipulate bits, one must use bitwise logic, confusing to some people. <a href="https://stackoverflow.com/q/47981/16217248">Related Stack Overflow question</a>.</p>
<p>What if numbers could be <em>'indexed'</em> like arrays to access individual bits?</p>
<pre><code>int x = 10; // 1010 in binary
x[0]; // 0
x[1]; // 1
x[2]; // 0
x[3]; // 1

x[2] = 1;
x; // 14
</code></pre>
<p>This would be much easier to use than bitwise operators such as <code>|</code> and <code>&amp;</code>. But no languages I have heard of allow integers to just be blatantly treated as bit arrays.</p>
<p>I was wondering if there is a catch to implementing this. Do CPUs lack trivial instructions to manipulate bits in this manner, making this impractical to implement? What are the downsides to this feature that stopped most languages from adding them?</p>

<operators><numbers><arrays><bitwise-operators><booleans>
What are the disadvantages of this far-fetched idea: All integers can be treated as boolean arrays?
CC BY-SA 4.0
2023-05-18T00:14:43.310Z
In Swift, large integers are `Collection<Word>` for hardware reasons, but I think I prefer a collection of bits conceptually.
Bbrk24
CC BY-SA 4.0
2023-05-18T00:14:45.450Z
There are certainly plenty of languages with indexable bitfield and bit array types; are you interested particularly in the idea of implicitly overloading integer values to produce them?
Michael Homer
CC BY-SA 4.0
2023-05-18T00:15:39.580Z
@MichaelHomer Basically.
CPlus
CC BY-SA 4.0
2023-05-18T00:27:44.883Z
Ruby sort of allows integers to be indexed as if they were arrays, e.g. `x[i]` is equivalent to `x >> i & 1`. You can even use slices when indexing.
naffetS
<p>As integers (certainly positive integers) are representable in base 2 as binary numbers, and a binary internal representation is also most common, integers arguably <em>are</em> bit (Boolean) arrays. So the idea is not farfetched, nor can I see any disadvantages; accessing individual bits, slices and other array operations translate very easily into other types of operations, to the point you might call it syntactical sugar. It might be practical to distinguish between an integer value, and its array interpretation, this could be done in many ways - typecasting, a function, an operator; just for fun I will use the feminine ordinal indicator &quot;ª&quot; as a postfix operator for this in this answer. So for an integer i, iª is a bit array view of i. By bit, btw, I mean the integers 0 and 1. So 1ª = (1). As for 0, it could be 0ª = (0), or maybe 0ª = (). I don't know which one would be most practical, probably the first, although the second has some appeal as being perhaps most &quot;correct&quot;.</p>
<p>A bit of care needs to be taken with negative integers, though. The common 2-complement representation might mess things up a bit (!), especially with slices. For natural numbers i, there is a nice equality: length(iª) = ceil(log2(i+1)). But (-1)ª would be (...,1,1,1,1). So maybe it is better to restrict iª to i ≥ 0.</p>
<p>In 2-complement, -i = (~i)+1, where ~ is complement or bitwise negation as known in C. Now, having bit arrays, it would make sense to move bitwise operations from the integer domain over to the bit array domain. (In the past, I think languages like PL/1 and Algol 68 did this too.) Which is probably a good thing, as I think in for example C, bitwise operations have caused various errors. Having both signed and unsigned integers of various lengths, and automatic promotion among them, makes bitwise operations in C more complicated than one would have guessed.</p>
<p>Using bit arrays that always represent natural numbers makes this a lot simpler. So this would be a strong <em>advantage</em> of this idea, I'd say!</p>
<p>But why restrict array-fication to binary? Outside the world of computing, we usually use base 10. iºb could be used for the general case of making an array using base b, iª = iº2.</p>
<p>Converting bit arrays, or other digit arrays, to integers is also straightforward. Just use the arrays as vectors, and you can go from bit array a = iª back to i just by the scalar product i = a·b, where b = λn:2ⁿ, or (1, 2, 4, 8, 16, ...)</p>
<p>Fun exercise: How about iº1?</p>

CC BY-SA 4.0
2023-05-18T10:10:03.083Z
2023-05-18T10:10:03.083Z
LHP
<blockquote>
<p>I do not know of any languages that support this idea</p>
</blockquote>
<p>Let's fix that :-)</p>
<p><a href="https://github.com/Vyxal/Vyxal" rel="nofollow noreferrer">Vyxal</a> is a <a href="https://en.wikipedia.org/wiki/Code_golf" rel="nofollow noreferrer">code golf</a> language which allows indexing into an integer as if it was a collection of digits:</p>
<pre><code>1010 2i
</code></pre>
<p>This puts our integer <code>1010</code> and the 0-based, from-the-left index <code>2</code> on the stack, then <code>i</code>ndexes the former with the latter. <a href="https://vyxal.pythonanywhere.com/?v=1#WyIiLCIiLCIxMDEwIDJpIiwiIiwiIl0=" rel="nofollow noreferrer">Try it Online!</a></p>
<p>The same goes for <a href="https://ato.pxeger.com/run?1=m728JKM0Ly_faMGCpaUlaboWyw0NDA0UjDKXFCclF0PFYHIA" rel="nofollow noreferrer">Thunno 2</a> and <a href="https://tio.run/##yy9OTMpM/f/f0MDQQMHo8Ir//wE" rel="nofollow noreferrer">05AB1E</a>.</p>

CC BY-SA 4.0
2023-05-18T06:08:31.953Z
2023-05-18T08:03:19.550Z
2023-05-18T08:03:19.550Z
Adám
<p>I wouldn't store them as arrays, but you can certainly implement such a syntax efficiently. If you translate <code>x[0]</code> to <code>x &amp; 1</code> you'll get <code>0</code> if <code>x=10</code>. So you could access any bit by translating <code>x[i]</code> to <code>(x &gt;&gt; i) &amp; 1</code>.</p>
<p>For the assignment, you'd go about the same, you can use bit-wise or <code>|</code> and bit-wise and <code>&amp;</code> to manipulate x, so <code>x[i] = 1</code> would become <code>x = x | (1 &lt;&lt; i)</code> and <code>x[i] = 0</code> would become <code>x = x &amp; ~(1 &lt;&lt; i)</code>.</p>
<p>I think it would certainly be interesting if a language would allow any type to be indexed like an array</p>

CC BY-SA 4.0
2023-05-18T00:17:07.933Z
2023-05-18T18:28:50.483Z
2023-05-18T18:28:50.483Z
ruarq
CC BY-SA 4.0
2023-05-18T00:21:42.750Z
Assignment is a bit trickier: you can to do `x |= 1 << i` to set it, but `x &= ~(1 << i)` to clear it.
Bbrk24
CC BY-SA 4.0
2023-05-18T00:27:25.327Z
@Bbrk24 True! I just "coded" that off of my head, I knew there was gonna be a mistake somewhere :D
ruarq
<p>Strictly speaking, an &quot;array&quot; is a specific kind of data structure where elements are stored at contiguous, equally-spaced memory addresses. The smallest addressable unit of memory is typically one byte, so from just this consideration, an integer cannot be treated exactly as an &quot;array&quot; of booleans, because individual bits don't have memory addresses. But this is more of a pedantic note about terminology; really you want to know the pros and cons of integers being <em>indexable</em> to access their individual bits. The <code>a[i]</code> syntax is for accessing an element from a sequence by index, and the use of this syntax doesn't imply that <code>a</code> is an array.</p>
<p>So then why don't popular languages allow indexed access to the individual bits of an integer? Here are a few good reasons:</p>
<ul>
<li><p><strong>Confusing error messages</strong>. It's quite common for beginners to write <code>a[i]</code> thinking <code>a</code> is an array of integers, when it is actually an integer. A compiler which reports a type error <em>&quot;<code>a</code> is an integer, not an array&quot;</em> directly addresses their misapprehension, where <em>&quot;<code>a[i]</code> is a boolean, not an integer&quot;</em> would be less helpful.</p>
<p>I'd argue this reason alone is sufficient, because the intentional
use of this niche feature by experienced programmers would be much
less common than the accidental use by beginners.</p>
</li>
<li><p><strong>Most of the time, you don't want only one bit</strong>. Yes, you can use a boolean array to represent a set of integers, but most of the set operations you want to do ─ unions, intersections, complements, subtractions, subset tests ─ depend on the whole set, not just one element. These use cases are already supported with bitwise operators: <code>a | b</code>, <code>a &amp; b</code>, <code>~a</code>, <code>a &amp; ~b</code>, and <code>(~a &amp; b) == 0</code>.</p>
<p>The set operations which do care about individual bits are adding, removing, membership tests, and (occasionally) toggling. But these aren't that hard to write with bitwise operations: <code>a |= 1 &lt;&lt; i</code>, <code>a &amp;= ~(1 &lt;&lt; i)</code>, <code>(a &amp; (1 &lt;&lt; i)) != 0</code>, and <code>a ^= 1 &lt;&lt; i</code>. For membership tests and removal, the <code>a[i]</code> syntax would be slightly simpler ─ but for adding or toggling, the bitwise operations use fewer source tokens than indexed accesses would. If your language treats non-zero integers as &quot;truthy&quot; values, then you can write just <code>a &amp; (1 &lt;&lt; i)</code> for set membership.</p>
</li>
<li><p><strong>Names are better than numbers</strong>. When you do care about individual bits, it's often because you've assigned a specific meaning to each bit, as in a <a href="https://en.wikipedia.org/wiki/Bit_field" rel="nofollow noreferrer">bit field</a>. In this case the individual bits are logically more similar to the fields of an object, than the elements in an array; it's rare that you would want to access a bit dynamically by index, rather than by a statically known name.</p>
<p>So in these use-cases, you could write <code>flags[CONNECTED]</code> to access the &quot;connected&quot; flag as a Boolean value, but this requires declaring <code>CONNECTED</code> as the appropriate constant. Instead, you could just as well write <code>(flags &amp; CONNECTED) != 0</code>. Moreover, the syntax for creating the bitfield is simpler using the bitwise <code>|</code> operator, than indexed writes.</p>
</li>
</ul>

CC BY-SA 4.0
2023-05-18T02:29:58.437Z
2023-05-18T10:25:00.837Z
2023-05-18T10:25:00.837Z
kaya3
CC BY-SA 4.0
2023-07-26T23:04:41.447Z
hmm. I'll take `a[i] = 1`, `a[i] = 0`, `a[i] != 0`, and `a[i] ^= 1` any day over `a |= 1 << i`, `a &= ~(1 << i)`, `(a & (1 << i)) != 0`, and `a ^= 1 << i`
Eldritch Conundrum
CC BY-SA 4.0
2023-07-26T23:11:57.277Z
I think that the "Confusing error messages" would be entirely addressed by requiring a slightly more intentful syntax, such as `a.bits[i] = 1`
Eldritch Conundrum
CC BY-SA 4.0
2023-08-23T15:04:03.037Z
IMHO the fact that many times more than one bit is involved is probably the main reason. This _could_ perhaps be addressed, but with more "complicated" machinery, such as indexing with masks as in [C++ std::valarray](https://en.cppreference.com/w/cpp/numeric/valarray/operator_at).
Pablo H
<h2>It privileges one form of bit access over others</h2>
<p>Accessing a word as a bit vector can be useful in some circumstances, but even more useful is the ability to pack and unpack general bit fields. Things like the IPv4 header.</p>
<p><a href="https://i.sstatic.net/2CLQC.png" rel="noreferrer"><img src="https://i.sstatic.net/2CLQC.png" alt="IPv4 header fields" /></a></p>
<p>Expressive and precise bit field manipulation goes back at least to <a href="https://dl.acm.org/doi/pdf/10.1145/362919.362936" rel="noreferrer">BLISS</a> (see section 1, &quot;Storage&quot;). <a href="http://erlang.org/documentation/doc-5.1/doc/extensions/bit_syntax.html" rel="noreferrer">Erlang</a> also has native support for bit fields.</p>
<p>C and C++ also have bit fields, but their semantics is not specified; there is no requirement for an implementation to actually pack bit fields.</p>

CC BY-SA 4.0
2023-05-18T01:26:25.693Z
2023-05-18T01:26:25.693Z
Pseudonym
CC BY-SA 4.0
2023-05-18T01:29:31.617Z
This would be a non-issue with ranged indexing: `6[1:3]` could be `3.`
Bbrk24
CC BY-SA 4.0
2023-05-18T01:30:34.043Z
True, but there wasn't an example of that in the question.
Pseudonym
CC BY-SA 4.0
2023-05-19T01:31:45.733Z
It also raises the question of how you would implement assignment to an array slice. I hope your CPU has a `pdep` instruction, or this could get inefficient.
Pseudonym
<h1>It would encourage inefficient code</h1>
<p>90% of the time when you're doing individual bit lookups on an int, you're doing something &quot;wrong&quot;. E.g., this would encourage those who don't feel comfortable with bitwise OR to write something like this:</p>
<pre><code>function nor(x, y) {
    int z = 0;

    for (int i = 0; i &lt; 64; i++) {
        z[i] = 1 - (x[i] || y[i]);
    }
}
</code></pre>
<p>This takes potentially hundreds of times longer than a simple bitwise OR and NOT. Something this extreme would most likely be rare, but operations which can be implemented with a chain of a few bitwise operations, such as implementing checksum algorithms or splitting apart packets into fields, might appear to be good places to use bit indexing to a bitwise novice, discouraging learning how to &quot;do it right&quot; and encouraging dramatically slower code.</p>

CC BY-SA 4.0
2023-05-18T00:17:56.427Z
2023-05-18T00:17:56.427Z
rydwolf
CC BY-SA 4.0
2023-05-18T00:19:32.903Z
If an optimizer can vectorize code like this on regular numbers, would it not be able to "vectorize" bitwise math into regular operations?
Bbrk24
CC BY-SA 4.0
2023-05-18T00:22:15.667Z
@Bbrk24 Possibly, but when the complexity is higher (e.g., when multiple bitwise operations would need to be combined in a somewhat complicated way to recreate the behavior), I'm not sure how capable a compiler would be of reverse engineering it. E.g., a checksum algo implemented with a loop or two over the bits in the input.
rydwolf
CC BY-SA 4.0
2023-05-21T22:51:46.390Z
@Bbrk24 Vectorizing code like this on regular numbers is very challenging, and apparently often still fails for reasons not obvious to the programmer. Compiler writer work and optimization time could be spent on turning that into a NOR, but it's going to take a lot of time on both parts, time probably better spent elsewhere.
prosfilaes
# What are the disadvantages of this far-fetched idea: All integers can be treated as boolean arrays?
Posted by: username_0 on 2023-05-18
I do not know of any languages that support this idea but I just thought that since numbers are just bits, why should we not be able to access those bits directly? In most languages such as C or C++, to manipulate bits, one must use bitwise logic, confusing to some people. Related Stack Overflow question.
What if numbers could be 'indexed' like arrays to access individual bits?
int x = 10; // 1010 in binary
x[0]; // 0
x[1]; // 1
x[2]; // 0
x[3]; // 1

x[2] = 1;
x; // 14

This would be much easier to use than bitwise operators such as | and &. But no languages I have heard of allow integers to just be blatantly treated as bit arrays.
I was wondering if there is a catch to implementing this. Do CPUs lack trivial instructions to manipulate bits in this manner, making this impractical to implement? What are the downsides to this feature that stopped most languages from adding them?
**Tags:** operators numbers arrays bitwise-operators booleans
> **Comments:**
> **username_1**: In Swift, large integers are `Collection<Word>` for hardware reasons, but I think I prefer a collection of bits conceptually.  
> **username_2**: There are certainly plenty of languages with indexable bitfield and bit array types; are you interested particularly in the idea of implicitly overloading integer values to produce them?  
> **username_0**: @MichaelHomer Basically.  
> **username_3**: Ruby sort of allows integers to be indexed as if they were arrays, e.g. `x[i]` is equivalent to `x >> i & 1`. You can even use slices when indexing.  
---
## 6 answers
### Answer by username_6 on 2023-05-18. Score: 13 | Accepted answer
I wouldn't store them as arrays, but you can certainly implement such a syntax efficiently. If you translate `x[0]` to `x & 1` you'll get `0` if `x=10`. So you could access any bit by translating `x[i]` to `(x >> i) & 1`.

For the assignment, you'd go about the same, you can use bit-wise or `|` and bit-wise and `&` to manipulate x, so `x[i] = 1` would become `x = x | (1 << i)` and `x[i] = 0` would become `x = x & ~(1 << i)`.

I think it would certainly be interesting if a language would allow any type to be indexed like an array
> **Comments:**
> **username_1** (2023-05-18): Assignment is a bit trickier: you can to do `x |= 1 << i` to set it, but `x &= ~(1 << i)` to clear it.  
> **username_6** (2023-05-18): @Bbrk24 True! I just "coded" that off of my head, I knew there was gonna be a mistake somewhere :D  
---
### Answer by username_11 on 2023-05-18. Score: 8
It would encourage inefficient code
90% of the time when you're doing individual bit lookups on an int, you're doing something "wrong". E.g., this would encourage those who don't feel comfortable with bitwise OR to write something like this:
function nor(x, y) {
    int z = 0;

    for (int i = 0; i < 64; i++) {
        z[i] = 1 - (x[i] || y[i]);
    }
}

This takes potentially hundreds of times longer than a simple bitwise OR and NOT. Something this extreme would most likely be rare, but operations which can be implemented with a chain of a few bitwise operations, such as implementing checksum algorithms or splitting apart packets into fields, might appear to be good places to use bit indexing to a bitwise novice, discouraging learning how to "do it right" and encouraging dramatically slower code.
> **Comments:**
> **username_1** (2023-05-18): If an optimizer can vectorize code like this on regular numbers, would it not be able to "vectorize" bitwise math into regular operations?  
> **username_11** (2023-05-18): @Bbrk24 Possibly, but when the complexity is higher (e.g., when multiple bitwise operations would need to be combined in a somewhat complicated way to recreate the behavior), I'm not sure how capable a compiler would be of reverse engineering it. E.g., a checksum algo implemented with a loop or two over the bits in the input.  
> **username_12** (2023-05-21): @Bbrk24 Vectorizing code like this on regular numbers is very challenging, and apparently often still fails for reasons not obvious to the programmer. Compiler writer work and optimization time could be spent on turning that into a NOR, but it's going to take a lot of time on both parts, time probably better spent elsewhere.  
---
### Answer by username_7 on 2023-05-18. Score: 6
Strictly speaking, an "array" is a specific kind of data structure where elements are stored at contiguous, equally-spaced memory addresses. The smallest addressable unit of memory is typically one byte, so from just this consideration, an integer cannot be treated exactly as an "array" of booleans, because individual bits don't have memory addresses. But this is more of a pedantic note about terminology; really you want to know the pros and cons of integers being *indexable* to access their individual bits. The `a[i]` syntax is for accessing an element from a sequence by index, and the use of this syntax doesn't imply that `a` is an array.

So then why don't popular languages allow indexed access to the individual bits of an integer? Here are a few good reasons:

* **Confusing error messages**. It's quite common for beginners to write `a[i]` thinking `a` is an array of integers, when it is actually an integer. A compiler which reports a type error *"`a` is an integer, not an array"* directly addresses their misapprehension, where *"`a[i]` is a boolean, not an integer"* would be less helpful.

  I'd argue this reason alone is sufficient, because the intentional
  use of this niche feature by experienced programmers would be much
  less common than the accidental use by beginners.
* **Most of the time, you don't want only one bit**. Yes, you can use a boolean array to represent a set of integers, but most of the set operations you want to do ─ unions, intersections, complements, subtractions, subset tests ─ depend on the whole set, not just one element. These use cases are already supported with bitwise operators: `a | b`, `a & b`, `~a`, `a & ~b`, and `(~a & b) == 0`.

  The set operations which do care about individual bits are adding, removing, membership tests, and (occasionally) toggling. But these aren't that hard to write with bitwise operations: `a |= 1 << i`, `a &= ~(1 << i)`, `(a & (1 << i)) != 0`, and `a ^= 1 << i`. For membership tests and removal, the `a[i]` syntax would be slightly simpler ─ but for adding or toggling, the bitwise operations use fewer source tokens than indexed accesses would. If your language treats non-zero integers as "truthy" values, then you can write just `a & (1 << i)` for set membership.
* **Names are better than numbers**. When you do care about individual bits, it's often because you've assigned a specific meaning to each bit, as in a [bit field](https://en.wikipedia.org/wiki/Bit_field). In this case the individual bits are logically more similar to the fields of an object, than the elements in an array; it's rare that you would want to access a bit dynamically by index, rather than by a statically known name.

  So in these use-cases, you could write `flags[CONNECTED]` to access the "connected" flag as a Boolean value, but this requires declaring `CONNECTED` as the appropriate constant. Instead, you could just as well write `(flags & CONNECTED) != 0`. Moreover, the syntax for creating the bitfield is simpler using the bitwise `|` operator, than indexed writes.
> **Comments:**
> **username_8** (2023-07-26): hmm. I'll take `a[i] = 1`, `a[i] = 0`, `a[i] != 0`, and `a[i] ^= 1` any day over `a |= 1 << i`, `a &= ~(1 << i)`, `(a & (1 << i)) != 0`, and `a ^= 1 << i`  
> **username_8** (2023-07-26): I think that the "Confusing error messages" would be entirely addressed by requiring a slightly more intentful syntax, such as `a.bits[i] = 1`  
> **username_9** (2023-08-23): IMHO the fact that many times more than one bit is involved is probably the main reason. This _could_ perhaps be addressed, but with more "complicated" machinery, such as indexing with masks as in [C++ std::valarray](https://en.cppreference.com/w/cpp/numeric/valarray/operator_at).  
---
### Answer by username_10 on 2023-05-18. Score: 5
## It privileges one form of bit access over others

Accessing a word as a bit vector can be useful in some circumstances, but even more useful is the ability to pack and unpack general bit fields. Things like the IPv4 header.

[![IPv4 header fields](https://i.sstatic.net/2CLQC.png)](https://i.sstatic.net/2CLQC.png)

Expressive and precise bit field manipulation goes back at least to [BLISS](https://dl.acm.org/doi/pdf/10.1145/362919.362936) (see section 1, "Storage"). [Erlang](http://erlang.org/documentation/doc-5.1/doc/extensions/bit_syntax.html) also has native support for bit fields.

C and C++ also have bit fields, but their semantics is not specified; there is no requirement for an implementation to actually pack bit fields.
> **Comments:**
> **username_1** (2023-05-18): This would be a non-issue with ranged indexing: `6[1:3]` could be `3.`  
> **username_10** (2023-05-18): True, but there wasn't an example of that in the question.  
> **username_10** (2023-05-19): It also raises the question of how you would implement assignment to an array slice. I hope your CPU has a `pdep` instruction, or this could get inefficient.  
---
### Answer by username_4 on 2023-05-18. Score: 2
As integers (certainly positive integers) are representable in base 2 as binary numbers, and a binary internal representation is also most common, integers arguably *are* bit (Boolean) arrays. So the idea is not farfetched, nor can I see any disadvantages; accessing individual bits, slices and other array operations translate very easily into other types of operations, to the point you might call it syntactical sugar. It might be practical to distinguish between an integer value, and its array interpretation, this could be done in many ways - typecasting, a function, an operator; just for fun I will use the feminine ordinal indicator "ª" as a postfix operator for this in this answer. So for an integer i, iª is a bit array view of i. By bit, btw, I mean the integers 0 and 1. So 1ª = (1). As for 0, it could be 0ª = (0), or maybe 0ª = (). I don't know which one would be most practical, probably the first, although the second has some appeal as being perhaps most "correct".

A bit of care needs to be taken with negative integers, though. The common 2-complement representation might mess things up a bit (!), especially with slices. For natural numbers i, there is a nice equality: length(iª) = ceil(log2(i+1)). But (-1)ª would be (...,1,1,1,1). So maybe it is better to restrict iª to i ≥ 0.

In 2-complement, -i = (~i)+1, where ~ is complement or bitwise negation as known in C. Now, having bit arrays, it would make sense to move bitwise operations from the integer domain over to the bit array domain. (In the past, I think languages like PL/1 and Algol 68 did this too.) Which is probably a good thing, as I think in for example C, bitwise operations have caused various errors. Having both signed and unsigned integers of various lengths, and automatic promotion among them, makes bitwise operations in C more complicated than one would have guessed.

Using bit arrays that always represent natural numbers makes this a lot simpler. So this would be a strong *advantage* of this idea, I'd say!

But why restrict array-fication to binary? Outside the world of computing, we usually use base 10. iºb could be used for the general case of making an array using base b, iª = iº2.

Converting bit arrays, or other digit arrays, to integers is also straightforward. Just use the arrays as vectors, and you can go from bit array a = iª back to i just by the scalar product i = a·b, where b = λn:2ⁿ, or (1, 2, 4, 8, 16, ...)

Fun exercise: How about iº1?
---
### Answer by username_5 on 2023-05-18. Score: 2
I do not know of any languages that support this idea

Let's fix that :-)
Vyxal is a code golf language which allows indexing into an integer as if it was a collection of digits:
1010 2i

This puts our integer 1010 and the 0-based, from-the-left index 2 on the stack, then indexes the former with the latter. Try it Online!
The same goes for Thunno 2 and 05AB1E.
---
