https://kotlinlang.org logo
Join Slack
Powered by
If `Byte` is a `Number`, then why isn't a `Bit` /`...
# announcements
h
If 
Byte
is a 
Number
, then why isn't a 
Bit
/`Boolean`? Iirc, 
Boolean
isn't actually stored with just one bit in memory, but does that actually matter?
r
How it's stored doesn't really matter. When it comes down to it, everything is just stored as bytes. The difference is semantics. 
Byte
represents numeric values and can perform numeric operations. 
Boolean
doesn't.
h
Sure but isn't a 
Boolean
logically equivalent to a 
Bit
, which is a number
s
I guess the same reason a 
Char
is not a 
Number
r
Why do you say 
Bit
is a number? (Also, 
Bit
isn't a type in Kotlin, so that comparison doesn't really apply here).
h
What do non-ascii characters return when you call 
Char::toInt
?
For whatever reason a 
Byte
is a number, the same can be applied to a 
Bit
I'm saying 
Bit
does exist in Kotlin. it's just called 
Boolean
r
I guess that depends on how you would define 
Bit
. If you define it to be 
Boolean
, then it has nothing to do with 
Byte
.
h
A Bit is a 0 or 1. Logical operations with bits are logically equivalent to those performed with booleans. If two things are logically identical, they are the same thing.
r
Then that's not a 
Boolean
. A 
Boolean
is 
true
or 
false
. Not 
1
or 
0
. They may be represented the same in memory, but that's irrelevant.
h
but in bit arithmetic 1==true, 0==false. all digital computation is based on Boolean logic by way of bit arithmetic. in bit arithmetic a bit is a True/False value.
r
They aren't logically identical by definition. `Boolean`s are logical, and that definition of 
Bit
is numerical. You seem to be operating off the assumption that 
1 === true
and 
0 === false
, which isn't true. (Sorry, I started writing that before I saw your message)
h
Why are logical and numerical mutually exclusive?
r
Not mutually exclusive, just orthogonal.
h
I apologize if I sound combative. I'm not arguing to win, more to explore a concept
r
If 
Bit
were defined, it could be done in a way that makes it logical and numerical. 
Boolean
just isn't.
Same here 🙂 I quite enjoy these kinds of discussions. They can make you rethink some of your assumptions, which can be very useful.
h
I guess my point is there need not be such a distinction. It is the same point as "Why does Kotlin/Java treat the boolean 
&&
differently from the bitwise 
and/&
? Shouldn't 
true xor false
compile? It doesn't because true and false are not bitwise values, but in boolean logic if two statements have identical truth tables, they are logically equivalent; bitwise 
and
and logical 
&&
have identical truth tables. Same goes for all bitwise and boolean unary and binary functions
r
In some languages it is true that 
1 == true
and 
0 == false
, but in others that's not true. Even if they are represented the same internally, it often makes sense (especially in strongly typed languages) to have them be semantically separated.
h
I guess I also question the lack of boolean xor, nor, nand in the language, too
r
I'm pretty sure 
xor
is there, but not 
nand
or`nor`.
h
the only one of which that is actually felt missing however is 
xor
.
There's a 
Boolean::xor
?
I know there's a bitwise one
r
h
oh shit
my bad. I guess I just assumed it didn't exist since 
and
and 
or
are exclusive to bitwise operations
r
Yeah, there are a few downsides to infix vs operator. Unfortunately the existence of bitwise operators (while super useful) do blur the logical vs numerical distinction, but that could be cleared up by assuming a 
Bit
type that is both numerical and logical and handles conversion to/from number types.
h
🤫 That line is so blurry because it actually doesn't exist...
r
😆
I guess you also then have to figure out if maybe 
true == 1
but 
true !== 1
...
h
Should they hash to the same value?
r
Sure but lot's of things that hash to the same value aren't equal.
h
I mean. 1L !== 1 We're already pretty comfortable with different number types
Boolean
would just extend 
Number
and be comparable to other `Number`s.
I actually don't know what 
===
vs 
==
distinction is in kotlin. I initially assumed 
===
meant equal hashcodes or that they must be the same javaclass, and that 
==
was using 
compareTo
operator, but that is not the case.
s
===
compares the instance reference.
==
executes the 
equals
method
r
That's not exactly true for primitives (which most numbers are as well as booleans)
h
therefore the only way to use 
operator compareTo
to compare equivalency between 2 instances is to do 
x.compareTo(y) == 0
? That's pretty silly
s
True… for primitives, 
==
and 
===
are the same
No, 
==
should suffice for equivalency.
h
Well I know the following doesn't compile:
Copy code
when(myLong) {
    0 -> ... // type mismatch Int/Long
    1 -> ... // type mismatch Int/Long
    else -> ...
}
s
Hmmm… I thought 
equals
takes an 
Any?
as input parameter….
h
🤷‍♂️ I tried it today
s
This maybe an additional check for a 
when
clause by the compiler…. Wonder if the 
Number#equals
enforces the receiver and the input parameter to be of the same class.
r
No, this comes down to primitive being special. There is no actual 
equals
function for primitives on the JVM.
s
True, but Kotlin is not just JVM…
h
s
Something odd going on with Numbers with regards to `equals`… You can replace 
myLong == 0
, which won’t compile with 
myLong.equals(0)
, which does compile, but still complains
Going back to the JVM, this is how 
equals
is implemented for a java.lang.Long:
Copy code
public boolean equals(Object obj) {
        if (obj instanceof Long) {
            return value == ((Long)obj).longValue();
        }
        return false;
    }
r
There's a fair amount of rewriting going on with the Kotlin compiler
s
If the input parameter is not a 
Long
, it will return false. Since it will always be false, 
myLong == myInt
will not compile, since it always will return 
false
…
h
Oh, and @streetsofboston 
Char
is a 
Number
in Kotlin
s
Copy code
public class Char private constructor() : Comparable<Char>
h
Oh, actually it isn't
i got confused because all `Number`s must include 
toChar
thank you
6 Views
Open in Slack
PreviousNext
Powered by