The complexity here seems like a good argument in favor of an Option or Maybe type with supporting operations, thought that might require some form of pattern-matching to be ergonomic and then we're off to statically-typed FP land :)
On Tuesday, October 31, 2023 at 9:21:58 AM UTC-4 Lifepillar wrote: > I don't know anything about the implementation, unfortunately. Maybe, I'll > find some time to start digging into the code some day. > > Just to be clear, when I say that the semantics should be revised, I mean > to go through what has been implemented, and resolve inconsistencies and > reduce the number of idiosyncracies in the most logical way. I'm not > proposing to scrap everything (it's not in the spirit of how Vim is > developed). > > For instance, some types (job, channel, function, …) have no obvious > default value, so if they are declared without being initialized they are > left undefined (“null”). Therefore, var j: job and var j: job = null_job > mean the same thing (afaict). Besides, it is possible to switch between two > states: “defined” (not null and not null_<type>) and “cleared” (both null > and null_<type>): > > var j: job # undefinedecho j == null # trueecho j == null_job # > true > j = job_start() # definedecho j == null # falseecho j == null_job # > false > j = null_job # cleared (undefined again)echo j == null # trueecho j > == null_job # true > > So far, so good. On the other hand, types with a “neutral” value, such as > numbers, lists, dicts, … are implicitly initialized to a default value if > no initializer is provided (see :help E1022). *But*, var l: list<bool> is > *not* the same as var l: list<bool> = []: > > var l1: list<bool>var l2: list<bool> = []echo l1 == [] # trueecho l1 > == null_list # trueecho l1 == null # true <==echo l2 == [] # > trueecho l2 == null_list # trueecho l2 == null # false <== > > There are now three distinguishable states: “uninitialized or cleared” ( > null and null_<type>), “initialized at declaration time” (null and not > null_<type>), “defined” (not null and not null_<type>). Why the > intermediate state? > > This is the kind of things that, imo, needs some attention. > > — > Reply to this email directly, view it on GitHub > <https://github.com/vim/vim/discussions/13458#discussioncomment-7435254>,. > You are receiving this because you are subscribed to this thread.Message > ID: <vim/vim/repo-discussions/13458/comments/7435...@github.com> > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/165e9e8a-f485-4691-bf56-dafda108fb02n%40googlegroups.com.
