Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP][Typing/typecore.ml]: Added warning 68, matching a function type #9395

Closed
wants to merge 1 commit into from

Conversation

muskangarg21
Copy link
Contributor

#6881
@Octachron

  • This test case seems to be the problem now.
# match fun x -> x with x -> x, x;;  
Warning 68: Trying to match a function type.
- : ('a -> 'a) * ('b -> 'b) = (, )
  • For now I have added a very basic test case, will add more after your suggestions.
  • The descriptions and name associated to the newly added warning 68 needs to be discussed.
    I will improve the code structure and add the Changes files once the PR reaches to its working state.

Thanks a lot for all the help

@@ -775,6 +779,8 @@ let descriptions =
64, "-unsafe used with a preprocessor returning a syntax tree";
65, "Type declaration defining a new '()' constructor";
66, "Unused open! statement";
(* 67, "ask octachron" *)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, the short description for the unused functor argument warning is missing. If you want to add the missing text, it would make for a fine separate PR. Otherwise, myself (or @trefis) will fix the issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I ll add it.

@Octachron
Copy link
Member

Concerning the failing tests, you can deactivate the warning locally with match[@warning "-68"]

exists_general_pattern { f = fun (type k) (p : k general_pattern) ->
match p.pat_desc with
| Tpat_exception _ -> true
| _ -> false } pat
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a quite self-contained function that is used in two different places. It is often better in this situation to make the function a toplevel helper function shared between the two call sites.

@trefis
Copy link
Contributor

trefis commented Mar 27, 2020

Sorry to be the grumpy one, but I think this PR is premature. I don't think there's a consensus around the idea behind this PR, i.e. I don't think the silence that followed @damiendoligez's proposal was an approving one.

I am personally not convinced by the approach, matching on a function type is not necessarily a mistake. The issue lies with the ignoring of the result, not with the match itself. And while we do not have a satisfying answer to that issue yet, I'm not keen on adding "workaround" warnings.

@Octachron
Copy link
Member

You are perfectly right to express your disagreement, and thanks for stating it early.

Do you have in mind a precise example in which matching on a syntactic value that is function (or any other type that cannot be destructured) is not a mistake?

@Gbury
Copy link
Contributor

Gbury commented Mar 27, 2020

Matching on a partial application of a function to catch an exception in the construction of a cloture might be a reasonable use I'd guess ?

@Octachron
Copy link
Member

Octachron commented Mar 27, 2020

I agree, this is why I added the "syntactic value" clause. And the current code only emits a warning if there are not exception pattern in the cases of the match.

@Octachron
Copy link
Member

I am closing this PR as non-consensual, partially subsumed by #10328 and not being currently active.

@Octachron Octachron closed this Apr 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants