option(int), int?, nil and none

[mppf]

We have been expecting to add support for generalized option types, so that e.g. int? will mean "an integer or a lack of an integer". We have also tossed around the idea of using option(int) as an alternative name for this type.

Now, given that MyClass? has the lack-of-a-value represented by nil, should int? also have the lack-of-a-value represented by nil as well? Or, should it use none?

Are we sure that we need both none and nil? It seems in some ways desireable, when working with something like an option(int) to check it against none (since "None" is the typical name for the lack-of-a-value in many languages). But it also seems desirable to check it against nil so that the option type can behave consistently with classes and value types (especially for generic code). If we keep both none and nil could we allow them to be used interchangeably in some cases?

[utkarsh147-del]

I want to work on this issue.Please give this chance to me.

[vasslitvinov]

Using none in this context looks tricky, as it is supposed to be removable by the compiler according to the spec. nil looks more promising in this regard.

[mppf]

hi @utkarsh147-del - this is an issue for a language design discussion (note the Design and Language tags). While we're happy to hear thoughts on it, it's not a great starting point for a new contributor. Please see https://chapel-lang.org/contributing.html if you haven't already.

[mppf]

@vasslitvinov - right, the current spec language points in the direction of an int? being possibly nil (rather than none).

[dlongnecke-cray]

I would prefer the type option(int) instead of special cased syntax like int?.

I think Rust-style enums (tagged unions/sum types) could solve this problem elegantly without the need for specialized syntax [edit: I forgot, but assuming you can overload postfix ?, I'm not that opposed]. We could incorporate the option type as one such enum. I've noticed the issue https://github.com/chapel-lang/chapel/issues/11453 was created to discuss the possibility of adding Rust-style enums.

If we have to go the ? approach, I would agree with @vasslitvinov that comparing against nil looks more promising.

[mppf]

I would prefer the type option(int) instead of special cased syntax like int?. I forgot, but assuming you can overload postfix ?, I'm not that opposed

So are you saying you have a minor preference for option(int) ? Re variant types - let's keep this issue focused on whether we would want users to write int? or option(int) or what.

Supposing we had option(int) would you want it to use nil or none for the absence of a value?

[dlongnecke-cray]

I prefer option(int).

In a perfect world, I'd prefer none over nil.

[e-kayrakli]

From a purely design perspective, is there a reason we'd want to avoid int? and want option(int) instead? I don't see a strong case for option(int) beyond int is not a pointer-based type and nilability is not an applicable concept. Personally that doesn't bother me. I can intuitively say that int? means "either an int or just nothing".

Unless I am missing something I find option to be unnecessarily too much typing for a concept that we (almost) already have in the language. Besides, if we were to add option, I think we should also support option(MyClass) and I like that even less :)

I don't have a preference between none and nil.