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


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:


 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:


 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
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) 

 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 parent reply "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) 

 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
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:


 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 reply 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:


 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
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) 

 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
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 
 
 

 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



 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




discourages nulls.  Even Anders went on video saying that he 


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




 Even Anders went on video saying that he regretted making reference


 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




 Even Anders went on video saying that he regretted making reference


 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




 Even Anders went on video saying that he regretted making reference


 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:


 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 reply 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:


 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
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) 

 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 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) 

 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 reply "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


 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
parent reply "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


 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
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) 

 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 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 
 
 

 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
 
 

 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 parent reply "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
 
 

 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
parent reply "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) 

 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
parent reply "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
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 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


 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
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 "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
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 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 reply "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
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