Why isn’t it allowed to pass the constant `0` to a...
# announcements
m
Why isn’t it allowed to pass the constant
0
to a
Double
? Why
0.0
?
p
Because 0 is an int and not a double?
z
Unlike Java, kotlin doesn't convert number literals for you. This gives some of the reasoning.
m
@Paul Woitaschek no, it’s a number literal with no type. It only becomes an
Int
when inferring a type. @Zach Klippenstein (he/him) [MOD] actually Kotlin does.
p
Uh now that's interesting!
Where can I read up on this?
m
I don’t know but the link that @Zach Klippenstein (he/him) [MOD] mentioned is a good starting point. It’s actually mentioned there but for some reason it’s not available for floating point. See comment of first line.
👍 1
It would be great to have
0
as universal unitless value. In
kotlin-css
for example we could just write
top = 0
instead of
top = 0.px
. But that’s another more advanced use case 😄
No,
null
is absence of value.
0
means
0
. Whether the
div
is
0
cm
,
px
or
rem
away from the top doesn’t matter - it’s at the top. Hence it’s just
0
in CSS.
null
would mean that the distance to top is not defined.
Once it has a type then yes. But a unitless
0
can be converted in any type that supports it. Just like we have in Kotlin already:
Copy code
val int: Int = 0
val long: Long = 0 // implies 0L

if (int == long) // not allowed
The same way I could write
Copy code
marginTop(0)
And allow that only for integer
0
and no other. The respective overload would resolve that properly and it only works if explicitly supported.
Yeah that’s why I don’t like
kotlin-css
and have written my own library. Properties are too inflexible, functions are much better here.
Zero
could work the same way as
Nothing?
does. It only has one valid value. Only difference is that it is inferred as
Int
and
Zero
is only used explicitly.
I wouldn’t add a conversion feature unless Kotlin gets one in general. Thus I’d only support it for parameter overloads, just like
Nothing?
.
top(0)
With
Copy code
fun top(value: Zero) {
    top(LinearDimension("0")) // example
}
fun top(value: LinearDimension) { … }
0
is not a matrix and thus wouldn’t be an acceptable value. In that case you’d probably use
Matrix.identity
or alike.
That’s why it should be explicit.
vax x = 0
//
Int
vax x: Zero = 0
//
Zero
Just like
var x = 0
//
Int
var x: Long = 0
//
Long
It doesn’t even have to be a real type. It could just be valid for overload resolution and parameters with that value are actually
Int
on the callee side - or totally inaccessible.
0
on its own has no type. Otherwise you couldn’t assign it to
Byte
,
Long
, etc.
Another path would be similar to what Swift does.
Copy code
class LinearDimension(val value: String) {
   companion object: ZeroConstructible {
      override fun constructFromZero() = LinearDimension("0")
   }
}

val foo: LinearDimension = 0
It’s an API that specifies how types can be constructed from literals. It’s not type coercing.
They don’t have it for
0
specifically. They have for
IntegerLiteral
,
FloatLiteral
,
StringLiteral
,
ListLiteral
(e.g. for Set construction) etc.
+
MapLiteral
That’s a potential explosion of overloads though
Zero
would be already but still an acceptable trade-off for simpler CSS API.
That would be incorrect
You can have unitless
0
but not unitless
1
in CSS.
1
needs a unit and cannot be implicitly pixel.
Actually there are cases in CSS where you must remove the unit from
0
. For example in some
calc(…)
expressions. So
0
should never implicitly become
0px
.
Why not? We could use
0
everywhere where it has the same meaning.
Int
,
Byte
,
Long
,
Double
and customs like
css.LinearDimension
.
We’re mixing up two things though. My initial question was about
0
for
Float
and
Double
😄
css.LinearDimension
is about literal
0
not the
Int
value
0
It would be more like a special case of integer literal that can be specifically addressed.
A zero literal
That’s okay. Doesn’t need to be solved by now :) It’s a topic for another day. And also more in the DSL space where it would be quite useful. Maybe in Math too, I don’t know. Back to using
0
literal for floating-point values.
z
yall might be interested in the #C0B9K7EP2 and #CQ3GFJTU1 channels if you’re not already in them