This is a minor thing, but I find `Option.fromNull...

# arrow

[sam]

This is a minor thing, but I find Option.fromNullable to be very verbose. Isn't the point of option that you may or may not have a nullable value, and so shouldn't Option(t) accept a nullable ?

[streetsofboston]

I’m not absolutely sure, but I think you can have an optional nullable value ala Option<T?>, where null is a valid value and None would mean not even a value of null.

[sam]

What I mean is, val name: String? = ... Option(name)

[sam]

So in scala, if I do Option(null) I get a None

[streetsofboston]

var nameFromServer : Option<String?>
...
nameFromServer = just(null) // no name
...
nameFromServer = none() // no value, not even a null-value
....

(not sure if the T in Option<T> is bound to Any or `Any?`…)

[streetsofboston]

Although, I would hate it if someone actually did this… 🙂

[sam]

I guess you're not familar with scala

[sam]

Option(null) == None

[sam]

The option apply method in scala is checking for null, and returns either a Some (Just) or a None, depending on the null check

[sam]

like .fromNullable is doing in arrow

[sam]

Given that you use Options precisely when want to deal with the possibility of nulls I was surprised that the arrow Option constructor is not doing the same thing.

[streetsofboston]

But if an Option can be defined to be able to accept null values as valid values, then Option(null) should not return a None (it should return Some(null))…. that is when you’d use fromNullable, i think, to get a None when the value is null.

[sam]

If you want a Some(null) in Scala, then you must use the Some constructor

[sam]

you can't use the Option constructor to get a some that actually contains a null

[sam]

And since that's (usually) a stupid thing anyway, the scala defaults make sense

[streetsofboston]

Ah… I see!
But yes, I’m not familiar with Scala 🙂

[sam]

I don't see the point in having an Option constructor that only accepts a non-null value

[sam]

if I know I have a non-null value, then why am I bothering with option in the first place

[streetsofboston]

I see that the Companion of Option has a `fun invoke(value: A): Option<A>`… and it doesn’t accept nullable types… you’re right. Why is it there then?

[sam]

I dunno

[sam]

Option.fromNullable is what I'm using

[sam]

but it's horribly verbose

[sam]

option.orElse { Option.fromNullable(name) }.orElse { Option.fromNullable(city) }

[pakoito]

We used to have fromNullable as an extension of T?. I believe someone complained and we deleted it?

[streetsofboston]

Hahahaha 🙂

[sam]

lol

[streetsofboston]

Is such an extension function in another arrow library?

[sam]

fromNullable whether it is an extension or not is still verbose

[sam]

maybe add .option() to T?

[sam]

Then it's no difference to Option(t) really

[sam]

I can add this as a PR if you want

[streetsofboston]

There is a fun <T> T?.toOption() that returns a Some or None

[sam]

yessssss

[streetsofboston]

It is in arrow-core-data
https://github.com/arrow-kt/arrow/blob/master/modules/core/arrow-core-data/src/main/kotlin/arrow/core/Option.kt

[sam]

perfect

[sam]

👍🏻🎉

[streetsofboston]

@pakoito
Should the toOption be defined as fun <T> T.toOptions(): Option<T>, where the extension-receiver no longer has a ? (fun <T> T?.toOptions(): Option<T>). I don’t think the ? is needed, since <T> upper-bound is already the nullable Any?

[raulraja]

Since T is not constrained to Any, Just specifying T makes this function FORALL T including T?

[raulraja]

heads up to everyone discussing adding new constructors

[raulraja]

We have plans to make a full pass to every data type constructor to eliminate syntactinc constructor and making them follow the same conventions as in the standard library

[raulraja]

for example:

[raulraja]

option(1), some(1), right(1)

[raulraja]

those style of constructor will be top level and they will have alternative constructors that resemble the type class methods:

[raulraja]

Option.just(1)

[raulraja]

We are trying to match the Kotlin style most users follow so it plays nicely with the std lib and users known idioms

[raulraja]

Additionally several users have complained of proliferation of constructors and syntax getting confused as to if there are differences between things like 1.left() and Either.Left(1) or Left(1), or Either.left(1)

[raulraja]

IMO we’ve gone wild adding syntax for the fun of it and it’s not even consistent across data types. Many are missing syntax and others have excessive.

[raulraja]

If people want to help with this task we can add also the Option/Nullable biz in the same PR or it may be at risk of getting removed if it does not follow the standards we are trying to establish.

[raulraja]

The only issue with the data types is that they have been contributed by different authors but we had no strong style guides at the time and now we are approaching 1.0 we need a cohesive and reasonable story for users to not get lost when they use Arrow.

[sam]

Seems like an excellent idea to use the top level functions as constructors