Skip to content

Use idiomatic/canonical option type annotations in Result module #14465

Closed

Description

@cmeeren

Result.toOption has return type Option<'T>. The idiomatic/canonical notation is 'T option. The use of Option<'T> here means that Option<'T> shows up in code/line lens and tooltips all over my codebase when using this function, whereas I would prefer 'T option.

I haven't checked, but I am guessing that this could apply to other functions in the Result module, too.

For completeness, note that the same kind of issue would also apply to functions typed with List<'T> instead of 'T list, and other similar types. (I haven't checked or encountered any, though.)

Activity

  1. added this to the Backlog milestone on Dec 12, 2022
  2. 1eyewonder commented on Dec 22, 2022

    @1eyewonder

    Are we asking to just update the signature file for result to show something like this or am I misunderstanding the issue?
    image

  3. cmeeren commented on Dec 22, 2022

    @cmeeren
    ContributorAuthor

    I don't know much about signature files vs. implementation files, but that's the transformations I am thinking of, yes. Except you should use voption instead of ValueOption, if I recall correctly.

  4. cmeeren commented on Dec 22, 2022

    @cmeeren
    ContributorAuthor

    These replacements could be done in all signature files, by the way, not just those pertaining to the Result module. (I don't know of any, but search/replace should make this easy.)

    If you agree, I can make a PR for this. A couple of questions:

    • Apart from option, voption, and list, which other types have alternative canonical representations? What about 'a array, which is also 'a []? The code base should be consistent. I think I recall having seen @dsyme mention array notation in particular someplace, but I have no idea where or even when.
    • Is it OK with replacing one type per commit across all signature files?
  5. T-Gro commented on Dec 28, 2022

    @T-Gro
    Member

    I would recommend to limit a PR to a handful of "find/replace" operations and explain those in the PR.
    That way, even if the diff is big, it will be easy to review.

    Each replacement being a separate commit (with description telling which action caused it) sounds great.

    Array usage has been recently unified (@edgarfgp did a lot of work there), I am not sure if there are any things left.

  6. edgarfgp commented on Dec 28, 2022

    @edgarfgp
    Contributor

    Regarding array changes. The remaining work is tracked here #14329.

    • Update FSharp.Core API reference
    • Update docs
  7. cmeeren commented on Dec 28, 2022

    @cmeeren
    ContributorAuthor

    So I would only be changing to postfix lowercase notation in signature files for these?

    • option
    • voption
    • list
    • ref

    Apart from [], these are the only ones listed in the formatting guidelines, so I guess the list is complete.

  8. cmeeren commented on Dec 30, 2022

    @cmeeren
    ContributorAuthor

    Protip - GH doesn't notify about reactions, so only due diligence ensured I am now aware you agree and that I can proceed 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions