www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Option!T

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I talked to a programmer who knows Scala (among others) and he mentioned 
the usefulness of the Option type - a zero or one element collection 
(range in D terminology). Here's an article discussing it: 
http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html

We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a 
collection of exactly one value, but not a type for "a value of type T 
or nothing at all". Should we follow Scala's example and add it?


Andrei
Dec 10 2013
next sibling parent reply "JR" <zorael gmail.com> writes:
On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu 
wrote:
 We have only(x) (http://dlang.org/phobos/std_range.html#.only) 
 to be a collection of exactly one value, but not a type for "a 
 value of type T or nothing at all".

Is this not what Nullable!T is?
Dec 10 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/13 9:40 AM, JR wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote:
 We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a
 collection of exactly one value, but not a type for "a value of type T
 or nothing at all".

Is this not what Nullable!T is?

Nullable is not a range. Andrei
Dec 10 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/11/13 6:25 AM, qznc wrote:
 On Tuesday, 10 December 2013 at 18:15:58 UTC, Andrei Alexandrescu wrote:
 On 12/10/13 9:40 AM, JR wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote:
 We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a
 collection of exactly one value, but not a type for "a value of type T
 or nothing at all".

Is this not what Nullable!T is?

Nullable is not a range.

Nullable!T is a type for "a value of type T or nothing at all". It also provides a range interface if the T value is a range. Where would you use an explicit zero or one element range?

See the URL I posted in the opening of this thread. Andrei
Dec 11 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 12/10/2013 12:40 PM, JR wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote:
 We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a
 collection of exactly one value, but not a type for "a value of type T
 or nothing at all".

Is this not what Nullable!T is?

Nullable lacks compile-time enforcement that you handle the "does not exist" possibility. It turns it into a run-time issue.
Jul 01 2014
prev sibling next sibling parent reply Max Klyga <email domain.com> writes:
On 2013-12-10 17:28:26 +0000, Andrei Alexandrescu said:

 I talked to a programmer who knows Scala (among others) and he 
 mentioned the usefulness of the Option type - a zero or one element 
 collection (range in D terminology). Here's an article discussing it: 
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-
he-option-type.html 
 
 
 We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a 
 collection of exactly one value, but not a type for "a value of type T 
 or nothing at all". Should we follow Scala's example and add it?
 
 
 Andrei

Yes! Option is super useful. Use it all the time in Scala and Java (via Guava library). I suppose it will be defined as a range, so map will work on it? One of the useful things about options are the ability to chain them via flatMap, will this usecase be handled?
Dec 10 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/13 9:47 AM, Max Klyga wrote:
 On 2013-12-10 17:28:26 +0000, Andrei Alexandrescu said:

 I talked to a programmer who knows Scala (among others) and he
 mentioned the usefulness of the Option type - a zero or one element
 collection (range in D terminology). Here's an article discussing it:
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html


 We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a
 collection of exactly one value, but not a type for "a value of type T
 or nothing at all". Should we follow Scala's example and add it?


 Andrei

Yes! Option is super useful. Use it all the time in Scala and Java (via Guava library). I suppose it will be defined as a range, so map will work on it? One of the useful things about options are the ability to chain them via flatMap, will this usecase be handled?

Yah, looks like flatMap is also useful (independently from Option). Should actually be flatMap!(R, uint depth = uint.max). Andrei
Dec 10 2013
prev sibling next sibling parent reply "Yota" <yotaxp thatGoogleMailThing.com> writes:
On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu 
wrote:
 I talked to a programmer who knows Scala (among others) and he 
 mentioned the usefulness of the Option type - a zero or one 
 element collection (range in D terminology). Here's an article 
 discussing it: 
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html

I really came to love Option when I was working in F#. One of the things I love about F# is how the language strongly discourages nulls. Even Anders went on video saying that he regretted making reference types nullable in C#. Of course, there's no way to remove the nullable-by-default nature of reference types in D2, but a guy can dream. =]
Dec 10 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 10.12.2013 18:54, schrieb Yota:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote:
 I talked to a programmer who knows Scala (among others) and he
 mentioned the usefulness of the Option type - a zero or one element
 collection (range in D terminology). Here's an article discussing it:
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html

I really came to love Option when I was working in F#. One of the things I love about F# is how the language strongly discourages nulls. Even Anders went on video saying that he regretted making reference types nullable in C#. Of course, there's no way to remove the nullable-by-default nature of reference types in D2, but a guy can dream. =]

It would probably break a lot of code, but the Eiffel, Kottlin's approach could be used. In those languages, unless it is proven that a reference type is valid you cannot make use of its value. Eiffel http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf Kotlin http://confluence.jetbrains.com/display/Kotlin/Null-safety -- Paulo
Dec 10 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/13 10:21 AM, Paulo Pinto wrote:
 Am 10.12.2013 18:54, schrieb Yota:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote:
 I talked to a programmer who knows Scala (among others) and he
 mentioned the usefulness of the Option type - a zero or one element
 collection (range in D terminology). Here's an article discussing it:
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html

I really came to love Option when I was working in F#. One of the things I love about F# is how the language strongly discourages nulls. Even Anders went on video saying that he regretted making reference types nullable in C#. Of course, there's no way to remove the nullable-by-default nature of reference types in D2, but a guy can dream. =]

It would probably break a lot of code, but the Eiffel, Kottlin's approach could be used. In those languages, unless it is proven that a reference type is valid you cannot make use of its value. Eiffel http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf Kotlin http://confluence.jetbrains.com/display/Kotlin/Null-safety

Not that this is not worth discussing, but this is a different topic. I'm talking about ranges of zero or one elements. Andrei
Dec 10 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 10.12.2013 19:34, schrieb Andrei Alexandrescu:
 On 12/10/13 10:21 AM, Paulo Pinto wrote:
 Am 10.12.2013 18:54, schrieb Yota:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote:
 I talked to a programmer who knows Scala (among others) and he
 mentioned the usefulness of the Option type - a zero or one element
 collection (range in D terminology). Here's an article discussing it:
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html

I really came to love Option when I was working in F#. One of the things I love about F# is how the language strongly discourages nulls. Even Anders went on video saying that he regretted making reference types nullable in C#. Of course, there's no way to remove the nullable-by-default nature of reference types in D2, but a guy can dream. =]

It would probably break a lot of code, but the Eiffel, Kottlin's approach could be used. In those languages, unless it is proven that a reference type is valid you cannot make use of its value. Eiffel http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf Kotlin http://confluence.jetbrains.com/display/Kotlin/Null-safety

Not that this is not worth discussing, but this is a different topic. I'm talking about ranges of zero or one elements. Andrei

Ah ok
Dec 10 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Should we follow Scala's example and add it?

Making an Option a D Range means it becomes a Mondad :-) There's then a need for more awareness of Option!T in map/filter/zip. Related: https://d.puremagic.com/issues/show_bug.cgi?id=9086 Bye, bearophile
Dec 10 2013
parent Max Klyga <email domain.com> writes:
On 2013-12-10 18:35:37 +0000, bearophile said:

 Andrei Alexandrescu:
 
 Should we follow Scala's example and add it?

Making an Option a D Range means it becomes a Mondad :-) There's then a need for more awareness of Option!T in map/filter/zip. Related: https://d.puremagic.com/issues/show_bug.cgi?id=9086 Bye, bearophile

Actually for Option there is no need for special casing as it acts as an input range of one or zero elements, so all map/filter/etc. will just work
Dec 10 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu
wrote:
 We have only(x) (http://dlang.org/phobos/std_range.html#.only) 
 to be a collection of exactly one value, but not a type for "a 
 value of type T or nothing at all"

Option is being upgraded to handle an arbitrary (but compile time known) amount of values: https://github.com/D-Programming-Language/phobos/pull/1743
Dec 10 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/13 10:59 AM, monarch_dodra wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu
 wrote:
 We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a
 collection of exactly one value, but not a type for "a value of type T
 or nothing at all"

Option is being upgraded to handle an arbitrary (but compile time known) amount of values: https://github.com/D-Programming-Language/phobos/pull/1743

Interesting! There is the problem one can't represent "no element of type T" and "one element of type T" with the same type. There's also the unrelated issue that the result of the proposed only() is passed around by value, even after it has been partially discarded. Andrei
Dec 10 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 10 December 2013 at 19:26:27 UTC, Andrei Alexandrescu 
wrote:
 On 12/10/13 10:59 AM, monarch_dodra wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei 
 Alexandrescu
 wrote:
 We have only(x) 
 (http://dlang.org/phobos/std_range.html#.only) to be a
 collection of exactly one value, but not a type for "a value 
 of type T
 or nothing at all"

Option is being upgraded to handle an arbitrary (but compile time known) amount of values: https://github.com/D-Programming-Language/phobos/pull/1743

Interesting! There is the problem one can't represent "no element of type T" and "one element of type T" with the same type.

Objects can do it pretty well. They even segfault to when you forgot about it. in D that feature is integrated !
Dec 10 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 10 December 2013 at 19:26:27 UTC, Andrei Alexandrescu 
wrote:
 On 12/10/13 10:59 AM, monarch_dodra wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei 
 Alexandrescu
 wrote:
 We have only(x) 
 (http://dlang.org/phobos/std_range.html#.only) to be a
 collection of exactly one value, but not a type for "a value 
 of type T
 or nothing at all"

Option is being upgraded to handle an arbitrary (but compile time known) amount of values: https://github.com/D-Programming-Language/phobos/pull/1743

Interesting! There is the problem one can't represent "no element of type T" and "one element of type T" with the same type.

Hum... True. Well... "T[]", I guess :)
 There's also the unrelated issue that the result of the 
 proposed only() is passed around by value, even after it has 
 been partially discarded.

Yes, but that also means than slicing doesn't escape a references to temporaries about the go out of scope: It carries around its payload. But, I see no reason not to implement an "Option": The way I see it, it "completes" our range package. Each tool has its pros and cons. I'm also working on a "staticArray", that can create static arrays on the fly. That too can also be used just like "only", but it does not carry arround its data by value. I'll finish the ER, and the pull, and you'll get more details. It seems like very useful stuff to me anyways.
Dec 10 2013
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu 
wrote:
 I talked to a programmer who knows Scala (among others) and he 
 mentioned the usefulness of the Option type - a zero or one 
 element collection (range in D terminology). Here's an article 
 discussing it: 
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html

 We have only(x) (http://dlang.org/phobos/std_range.html#.only) 
 to be a collection of exactly one value, but not a type for "a 
 value of type T or nothing at all". Should we follow Scala's 
 example and add it?


 Andrei

Having a easy way to return a single element range which may be empty is probably a good idea. It could make a good change to style, but I don't use Option in other languages. For that reason I'm not sure Option range probably doesn't have the same semantics as expected by users of other languages.
Dec 10 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 10 December 2013 at 22:10:49 UTC, Jesse Phillips 
wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei 
 Alexandrescu wrote:
 I talked to a programmer who knows Scala (among others) and he 
 mentioned the usefulness of the Option type - a zero or one 
 element collection (range in D terminology). Here's an article 
 discussing it: 
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html

 We have only(x) (http://dlang.org/phobos/std_range.html#.only) 
 to be a collection of exactly one value, but not a type for "a 
 value of type T or nothing at all". Should we follow Scala's 
 example and add it?


 Andrei

Having a easy way to return a single element range which may be empty is probably a good idea. It could make a good change to style, but I don't use Option in other languages. For that reason I'm not sure Option range probably doesn't have the same semantics as expected by users of other languages.

That's a good point. `Option` is usually used with pattern matching, so the value is used in a clause that is only executed if it has a value(http://en.wikipedia.org/wiki/Option_type#Examples). This can easily be implemented in D: https://gist.github.com/someboddy/7902770
Dec 10 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 11 December 2013 at 00:08:49 UTC, Idan Arye wrote:
 On Tuesday, 10 December 2013 at 22:10:49 UTC, Jesse Phillips 
 wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei 
 Alexandrescu wrote:
 I talked to a programmer who knows Scala (among others) and 
 he mentioned the usefulness of the Option type - a zero or 
 one element collection (range in D terminology). Here's an 
 article discussing it: 
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html

 We have only(x) 
 (http://dlang.org/phobos/std_range.html#.only) to be a 
 collection of exactly one value, but not a type for "a value 
 of type T or nothing at all". Should we follow Scala's 
 example and add it?


 Andrei

Having a easy way to return a single element range which may be empty is probably a good idea. It could make a good change to style, but I don't use Option in other languages. For that reason I'm not sure Option range probably doesn't have the same semantics as expected by users of other languages.

That's a good point. `Option` is usually used with pattern matching, so the value is used in a clause that is only executed if it has a value(http://en.wikipedia.org/wiki/Option_type#Examples). This can easily be implemented in D: https://gist.github.com/someboddy/7902770

Actually, now that I think about it, many range functions from `std.algorithm` can also be useful for (the functional-languages') `Option`, provided they return an `Option`. Functions like `map` and `filter` can not return a collection with more entries than what they receive, so it might be worthwhile to specialize them to return `Option` instead of regular ranges. That way we can use them to manipulate the value inside the option(only if it exists!) and in the end use the `Option` API to safely treat it as a single value(that might not exist) instead of a range that as far as the compile care can contain any number of values, and we only happen to know it can't contain more than one.
Dec 10 2013
prev sibling next sibling parent "JR" <zorael gmail.com> writes:
On Tuesday, 10 December 2013 at 18:15:58 UTC, Andrei Alexandrescu 
wrote:
 On 12/10/13 9:40 AM, JR wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei 
 Alexandrescu wrote:
 We have only(x) 
 (http://dlang.org/phobos/std_range.html#.only) to be a
 collection of exactly one value, but not a type for "a value 
 of type T
 or nothing at all".

Is this not what Nullable!T is?

Nullable is not a range. Andrei

Right, I stand corrected and invoke TMYK.
Dec 11 2013
prev sibling next sibling parent "qznc" <qznc web.de> writes:
On Tuesday, 10 December 2013 at 18:15:58 UTC, Andrei Alexandrescu 
wrote:
 On 12/10/13 9:40 AM, JR wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei 
 Alexandrescu wrote:
 We have only(x) 
 (http://dlang.org/phobos/std_range.html#.only) to be a
 collection of exactly one value, but not a type for "a value 
 of type T
 or nothing at all".

Is this not what Nullable!T is?

Nullable is not a range.

Nullable!T is a type for "a value of type T or nothing at all". It also provides a range interface if the T value is a range. Where would you use an explicit zero or one element range?
Dec 11 2013
prev sibling next sibling parent reply Shammah Chancellor <email domain.com> writes:
On 2013-12-10 17:28:26 +0000, Andrei Alexandrescu said:

 I talked to a programmer who knows Scala (among others) and he 
 mentioned the usefulness of the Option type - a zero or one element 
 collection (range in D terminology). Here's an article discussing it: 
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-
he-option-type.html 
 
 
 We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a 
 collection of exactly one value, but not a type for "a value of type T 
 or nothing at all". Should we follow Scala's example and add it?
 
 
 Andrei

Did anything ever come of this? If there's nothing in Phobos yet, I can start working on it and submit a PR. If we can get this formalized and into the good usage, it seems like we would not need a .? operator. -Shammah
Jul 01 2014
next sibling parent reply "Sebastian Graf" <sgraf1337 gmail.com> writes:
On Tuesday, 1 July 2014 at 11:37:15 UTC, Shammah Chancellor wrote:
 On 2013-12-10 17:28:26 +0000, Andrei Alexandrescu said:

 I talked to a programmer who knows Scala (among others) and he 
 mentioned the usefulness of the Option type - a zero or one 
 element collection (range in D terminology). Here's an article 
 discussing it: 
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html
 
 
 We have only(x) (http://dlang.org/phobos/std_range.html#.only) 
 to be a collection of exactly one value, but not a type for "a 
 value of type T or nothing at all". Should we follow Scala's 
 example and add it?
 
 
 Andrei

Did anything ever come of this? If there's nothing in Phobos yet, I can start working on it and submit a PR. If we can get this formalized and into the good usage, it seems like we would not need a .? operator. -Shammah

I'd strongly vote against an Option type, because we already have Nullable (although I would much more like the nomenclature of Option). Nullable is trivial to convert into a range, the function of which could simply be provided in Phobos. Actually, like bearophile pointed out, it's not that Option is a range, but that ranges and Option are monads, e.g. mappable and flattenable. Being mappable and flattenable is no unique trait of ranges, that's where the mixup comes from I think. Of course, we could just say that "range" is D lingo for "monad", but that will be kind of strange in the long run...
Jul 01 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/01/2014 02:35 PM, Sebastian Graf wrote:
 Actually, like bearophile pointed out, it's not that Option is a
 range, but that ranges and Option are monads,

Option 'is' a range as much as it 'is'* a monad.
 e.g. mappable and flattenable.

i.e. empty, front, popFront have conforming implementations.
 Being mappable and flattenable is no unique trait of
 ranges,

It is also not everything there is to ranges. OTOH, every range 'is' a monad, so saying that Option 'is' a range is more precise than saying that it 'is' a monad
 that's where the mixup comes from I think.
 ...

The 'mixup' comes from implementing Option at a suboptimally high level of abstraction. More abstraction is unlikely to help here. :o) * (This is a little sloppy.)
Jul 01 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Tuesday, 1 July 2014 at 11:37:15 UTC, Shammah Chancellor wrote:
 On 2013-12-10 17:28:26 +0000, Andrei Alexandrescu said:

 I talked to a programmer who knows Scala (among others) and he 
 mentioned the usefulness of the Option type - a zero or one 
 element collection (range in D terminology). Here's an article 
 discussing it: 
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html
 
 
 We have only(x) (http://dlang.org/phobos/std_range.html#.only) 
 to be a collection of exactly one value, but not a type for "a 
 value of type T or nothing at all". Should we follow Scala's 
 example and add it?
 
 
 Andrei

Did anything ever come of this? If there's nothing in Phobos yet, I can start working on it and submit a PR. If we can get this formalized and into the good usage, it seems like we would not need a .? operator. -Shammah

I have a simple implementation that I've been working on off and on. It's kind of neat representing it as a range as you get all the range algorithms for free. One problem I ran into is that my first instinct is to use std.algorithm.map as the monadic bind operation, but it produces an option wrapped in a MapResult, which is no good. You could just implement map as a member function of Option!T, but it's not transparent, and it's more difficult to make it lazy.
Jul 01 2014
prev sibling next sibling parent "Sebastian Graf" <sgraf1337 gmail.com> writes:
On Tuesday, 1 July 2014 at 14:28:10 UTC, Meta wrote:
 On Tuesday, 1 July 2014 at 11:37:15 UTC, Shammah Chancellor 
 wrote:
 On 2013-12-10 17:28:26 +0000, Andrei Alexandrescu said:

 I talked to a programmer who knows Scala (among others) and 
 he mentioned the usefulness of the Option type - a zero or 
 one element collection (range in D terminology). Here's an 
 article discussing it: 
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html
 
 
 We have only(x) 
 (http://dlang.org/phobos/std_range.html#.only) to be a 
 collection of exactly one value, but not a type for "a value 
 of type T or nothing at all". Should we follow Scala's 
 example and add it?
 
 
 Andrei

Did anything ever come of this? If there's nothing in Phobos yet, I can start working on it and submit a PR. If we can get this formalized and into the good usage, it seems like we would not need a .? operator. -Shammah

I have a simple implementation that I've been working on off and on. It's kind of neat representing it as a range as you get all the range algorithms for free. One problem I ran into is that my first instinct is to use std.algorithm.map as the monadic bind operation, but it produces an option wrapped in a MapResult, which is no good. You could just implement map as a member function of Option!T, but it's not transparent, and it's more difficult to make it lazy.

std.algorithm.map corresponds to the arrow map (fmap) of the functor underlying the monad, it's not the bind operator. That's why you'll get the nesting, what you really want is flatMap, a map followed by a flatten operation (Phobos neither seems to include flatMap, nor an equivalent of flatten, just chain). The bind operator would correspond to flatMap.
Jul 01 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Sebastian Graf:

 (Phobos neither seems to include flatMap,

I'd like a fast flatMap in Phobos.
 nor an equivalent of flatten, just chain).

joiner? http://dlang.org/library/std/algorithm/joiner.html Bye, bearophile
Jul 01 2014
prev sibling parent "Sebastian Graf" <sgraf1337 gmail.com> writes:
On Tuesday, 1 July 2014 at 15:09:08 UTC, bearophile wrote:
 joiner?
 http://dlang.org/library/std/algorithm/joiner.html

 Bye,
 bearophile

Indeed.
Jul 01 2014
prev sibling next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu 
wrote:
 I talked to a programmer who knows Scala (among others) and he 
 mentioned the usefulness of the Option type - a zero or one 
 element collection (range in D terminology). Here's an article 
 discussing it: 
 http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.html

 We have only(x) (http://dlang.org/phobos/std_range.html#.only) 
 to be a collection of exactly one value, but not a type for "a 
 value of type T or nothing at all". Should we follow Scala's 
 example and add it?


 Andrei

I am strongly in favour of an option type and the range behaviour. You can express things like chain(optionalFoo, optionalBar, optionalBaz) and get a sequece of only non-optional values out of it. It's one of those sublte things where you might ask, "What's the point?" Once you use it a lot you can express some nice things with it. I'm also strongly in favour of Option/Maybe types in general, as a replacement for null. null is one of my pet hates, and things are much nicer when the lack of a value is represented in the type system. (T or Option!T)
Jul 01 2014
next sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2014-07-01 12:45:11 +0000, w0rp said:

 I'm also strongly in favour of Option/Maybe types in general, as a 
 replacement for null. null is one of my pet hates, and things are much 
 nicer when the lack of a value is represented in the type system. (T or 
 Option!T)

I would have disagreed with you in the past, but I just read some examples from Rust and other languages with strong type systems and I'm a convert. I'd like to see a compiler flag to turn off null assignment to reference types to enforce Option/Nullable to be used. I also liked garbage collected pointers being expressed by the type system. Clarifies when libraries are expecting to take ownership of a pointer, etc. -Shammah
Jul 01 2014
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2014-07-02 04:26:47 +0000, Wanderer said:

 On Tuesday, 1 July 2014 at 20:34:05 UTC, Shammah Chancellor wrote:
 On 2014-07-01 12:45:11 +0000, w0rp said:
 
 I'm also strongly in favour of Option/Maybe types in general, as a 
 replacement for null. null is one of my pet hates, and things are much 
 nicer when the lack of a value is represented in the type system. (T or 
 Option!T)

I would have disagreed with you in the past, but I just read some examples from Rust and other languages with strong type systems and I'm a convert. I'd like to see a compiler flag to turn off null assignment to reference types to enforce Option/Nullable to be used. I also liked garbage collected pointers being expressed by the type system. Clarifies when libraries are expecting to take ownership of a pointer, etc. -Shammah

Uhm, I'm sorry, but I don't see any difference between two approaches - null-not null vs. one value/no value. In both cases, there is a possibility of a situation when the value that "should be there", is not there. It can be either because it's not available yet, or because programmer made a mistake in the code. But in either case, when you try to use the value that's "not there" without cheking first, you get a runtime error. Correct me if I'm wrong, but "Option" being suggested here, is just a nullable reference in disguise.

I don't see a huge difference either. I didn't realize Nullable was already around. The main thing is that is valuable is that Nullable/Option extended to reference types, and then disabling the usual null assignment to references. The reason for this is that you can clearly discern when nulls are possible through the type system and when you need to check for them. Not every function should have to be prepared to check for nulls -- and can express that it doesn't by not accepting a Nullable type. I wonder if we could have a compiler flag to disable null references as an experiment. -Shammah
Jul 02 2014
parent Shammah Chancellor <anonymous coward.com> writes:
On 2014-07-02 12:04:03 +0000, Dicebot said:

 On Wednesday, 2 July 2014 at 11:48:18 UTC, Shammah Chancellor wrote:
 I don't see a huge difference either.   I didn't realize Nullable was 
 already around.  The main thing is that is valuable is that 
 Nullable/Option extended to reference types, and then disabling the 
 usual null assignment to references.

There is a very important difference when all other types considered non-nullable - something we can only achieve by convention in D.

Well. I'm not sure how much work it would be, but I'd like to investigate having a compiler flag that disables null references and leaves only null pointers available for C compatibility. I think it would be an interesting experiment. The D type system is certainly powerful enough to support going that direction (ala Rust, Haskell) -Shammah
Jul 02 2014
prev sibling next sibling parent "Wanderer" <no-reply no-reply.org> writes:
On Tuesday, 1 July 2014 at 20:34:05 UTC, Shammah Chancellor wrote:
 On 2014-07-01 12:45:11 +0000, w0rp said:

 I'm also strongly in favour of Option/Maybe types in general, 
 as a replacement for null. null is one of my pet hates, and 
 things are much nicer when the lack of a value is represented 
 in the type system. (T or Option!T)

I would have disagreed with you in the past, but I just read some examples from Rust and other languages with strong type systems and I'm a convert. I'd like to see a compiler flag to turn off null assignment to reference types to enforce Option/Nullable to be used. I also liked garbage collected pointers being expressed by the type system. Clarifies when libraries are expecting to take ownership of a pointer, etc. -Shammah

Uhm, I'm sorry, but I don't see any difference between two approaches - null-not null vs. one value/no value. In both cases, there is a possibility of a situation when the value that "should be there", is not there. It can be either because it's not available yet, or because programmer made a mistake in the code. But in either case, when you try to use the value that's "not there" without cheking first, you get a runtime error. Correct me if I'm wrong, but "Option" being suggested here, is just a nullable reference in disguise.
Jul 01 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 2 July 2014 at 04:26:50 UTC, Wanderer wrote:
 Uhm, I'm sorry, but I don't see any difference between two 
 approaches - null-not null vs. one value/no value.

 In both cases, there is a possibility of a situation when the 
 value that "should be there", is not there. It can be either 
 because it's not available yet, or because programmer made a 
 mistake in the code. But in either case, when you try to use 
 the value that's "not there" without cheking first, you get a 
 runtime error.

 Correct me if I'm wrong, but "Option" being suggested here, is 
 just a nullable reference in disguise.

You're exactly right. Where nullable is most useful is with types that don't have null values. Ints, floats, chars, etc. Then in some hypothetical function IndexOf, instead of returning -1 or int.max or throwing an exception or whatever else we can think up, we simply return a Nullable!int to specify that the index of a particular item may exist or not, depending on if that item is in the array. Nullable!int IndexOf(int[] arr, int val) { foreach (int i, n; arr) { if (n == val) { return Nullable!int(i); } } return Nullable!int(); } This pattern is very prevalent in functional languages, even when returning objects from functions, because many functional languages do not have nullable objects. Therefore, the concept of "null" is encoded in the type system as some kind of Option type.
Jul 01 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Wednesday, 2 July 2014 at 04:26:50 UTC, Wanderer wrote:
 Uhm, I'm sorry, but I don't see any difference between two 
 approaches - null-not null vs. one value/no value.

 In both cases, there is a possibility of a situation when the 
 value that "should be there", is not there. It can be either 
 because it's not available yet, or because programmer made a 
 mistake in the code. But in either case, when you try to use 
 the value that's "not there" without cheking first, you get a 
 runtime error.

 Correct me if I'm wrong, but "Option" being suggested here, is 
 just a nullable reference in disguise.

The difference between Option!T and allowing null references for T is that if you take away the possibility of T being a null reference, you never have to check for it, which reduces the number of bugs. Then you can create semantics for Option!T that force you to think about the possibility of lack of value. Options also kind of fit as ranges too, so in Scala you use map on option types, combine several Option[T] values together into a Seq[T], etc.
Jul 02 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 2 July 2014 at 11:48:18 UTC, Shammah Chancellor 
wrote:
 I don't see a huge difference either.   I didn't realize 
 Nullable was already around.  The main thing is that is 
 valuable is that Nullable/Option extended to reference types, 
 and then disabling the usual null assignment to references.

There is a very important difference when all other types considered non-nullable - something we can only achieve by convention in D.
Jul 02 2014
prev sibling parent "Sebastian Graf" <sgraf1337 gmail.com> writes:
On Tuesday, 1 July 2014 at 16:49:38 UTC, Nick Sabalausky wrote:
 On 12/10/2013 12:40 PM, JR wrote:
 On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei 
 Alexandrescu wrote:
 We have only(x) 
 (http://dlang.org/phobos/std_range.html#.only) to be a
 collection of exactly one value, but not a type for "a value 
 of type T
 or nothing at all".

Is this not what Nullable!T is?

Nullable lacks compile-time enforcement that you handle the "does not exist" possibility. It turns it into a run-time issue.

I'd say, if we include an Option type, then that type should wrap a Nullable rather than a range. Conversion to a range can still happen through a function, and Option could enforce proper pattern matching or ifHasValue!projection.orElse(nullValue); goo.
Jul 01 2014