Discussion: https://irclogs.nim-lang.org/06-03-2019.html#21:11:26

Well the module that contains the actual data type is now called optionals, but options still exists and does the same as before. So actually you don't need to change your code for this change (unless you want to get rid of the deprecated warning). As for why the modules where split in the first place was a two part thing. First I started adding things into the options module that some people really liked, and some people really didn't. This started a discussion on what should be in there and what shouldn't, and the possibility of implementing these things as a separate library instead. Looking into that I realised it would be a nice separation of tasks to have the data type and most rudimentary functionality in one module, and more high-level things in a separate procedure. This means it would be easier to import the small optionals file if all I want to do is return an Option[string] for example, especially now that nil can't be used in this context. If I wanted to actually work with a returned option I could import optionutils for a similar scheme as to what is present in options today or a third-party library that treated options in a different way (for example the one I based parts of my work on for my initial changes). Such libraries might collide or have weird effects if accidentally mixed with the stuff now moved to optionutils, but with the change they are free to implement their own interface without using a separate data type, like what the superfunc/maybe library has to do today.

@dom96 I am all in for this change, unless you have a nicer solution to shave off the Option type from it's less useful "utilities".

So actually you don't need to change your code for this change (unless you want to get rid of the deprecated warning).

So I will need to, if not today then at some point in the future because this code will get removed just like all deprecated things...

Again, there is no reason to rename this module. I don't see why it's not perfectly fine to just keep the type in the current options. If you want to move these functions then deprecate them in this module and move them.

As for your arguments for splitting this file up:

This means it would be easier to import the small optionals file if all I want to do is return an Option[string] for example, especially now that nil can't be used in this context.

Typing from options import Option is not hard if this is your objective.

Such libraries might collide or have weird effects if accidentally mixed with the stuff now moved to optionutils, but with the change they are free to implement their own interface without using a separate data type, like what the superfunc/maybe library has to do today.

With how things stand right now I don't see there being any conflict. Whether to include your changes is still debatable IMO, I think it would work in fact work better as a nimble package.

That's a good point, from options import Option would indeed work for most, if not all use cases for the optionals module.

And yeah, I will probably create a nimble package or two for my various options things.

Feels like it is arbitrary what ends up in one or another module, in practice we will import both. Also it makes it harder to locate what you were looking for.

This applies to sequtils vs algorithm, os vs osprosc, strutils vs strmisc, etc. Ideally every module would contain one type and related procs, in reality you have cases like sets (HashSet, OrderedSet) and intsets (IntSet), tables (Table, OrderedTable, CountTable, etc) strtabs (StringTableObj) and sharedtables (SharedTable), and cases like Option (optionals, optutils), without mentioning those things that are found in system.nim (newSeqOfcap, newSeqUninitialized, find, pop, add, etc).

I read from the logs that it is hard to find things with big modules. That's true, but the real problem is that it is not possible to tell what a proc does unless you read them one by one. That problem persist after splitting modules and the side index doesn't solve this. This is how java shows a summary of the methods contained in a class which makes it easier to find what you are looking for:

compared to nim:

With a summary it would not matter how many procs a module contains.
In my opinion you need to find a cohesive rule to group types/procs, instead of "as long as there is enough space".

@Wh1teDuke that's a nice solution to this problem too and goes back to what I've said multiple times now, but I will repeat it: what you are trying to solve in this PR is a doc gen problem, not a "modules are too big" problem.

Ok.