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

Type inference for a record/class behaves differently when module is open or not #1294

Closed
ant0nsc opened this issue Jun 28, 2016 · 2 comments
Labels
Bug Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code.

Comments

@ant0nsc
Copy link

ant0nsc commented Jun 28, 2016

In a module that defines a record R and a discriminated union type where one case is called R, type inference is able to distinguish between the 2 types when the module is open, but not when I qualify the type name with the module name.

Repro steps

module Module =
    type R = { a: int } with static member New = { a = 1 }
    type Choice = | R of R
open Module
// This is accepted, R is inferred to be the record type.
let record1 = R.New
let choice1 v =
    match v with
    | R r -> r
    | _ -> failwith "Nope."
// R is inferred to be of type Choice.R, hence R.New not recognized.
let record2 = Module.R.New
let choice2 v =
    match v with
    | Module.R r -> r
    | _ -> failwith "Nope."

Expected behavior

In record2, I would have expected that Module.R is inferred to be the record type.

Actual behavior

Module.R is inferred to be of type Choice.R

Known workarounds

Open the module.

Related information

Tested in Microsoft (R) F# Interactive version 14.0.23413.0, Windows 10, Visual Studio 2015.

Originally submitted here

@dsyme dsyme added Bug Area-Compiler Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code. and removed Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. labels Jun 29, 2016
forki added a commit to forki/visualfsharp that referenced this issue Sep 2, 2016
forki added a commit to forki/visualfsharp that referenced this issue Sep 2, 2016
@forki
Copy link
Contributor

forki commented Sep 2, 2016

proposed a fix in #1512

forki added a commit to forki/visualfsharp that referenced this issue Nov 22, 2016
forki added a commit to forki/visualfsharp that referenced this issue Nov 22, 2016
forki added a commit to forki/visualfsharp that referenced this issue Nov 23, 2016
forki added a commit to forki/visualfsharp that referenced this issue Nov 23, 2016
forki added a commit to forki/visualfsharp that referenced this issue Nov 23, 2016
forki added a commit to forki/visualfsharp that referenced this issue Nov 23, 2016
@dsyme dsyme closed this as completed in adff559 Nov 24, 2016
@FriedrichGretz
Copy link

This issue still persists, exactly as described by @ant0nsc.
Tested with

  • Microsoft (R) F# Interactive, Version 10.2.3 for F# 4.5, and
  • dotnet 2.1.401

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code.
Projects
None yet
Development

No branches or pull requests

4 participants