Fsharp: Cannot use new F# 4.7 features under .NET Core 3.0 FSI

[Youenn-Bouglouan]

It seems like the newly introduced F# 4.7 features do not work under FSI (or .fsx files) with the latest .Net Core SDK 3.0.100

Repro steps

1. Install latest .Net Core SDK 3.0.100 from here
2. Run dotnet fsi from the CLI
3. Check that FSI uses newest F# 4.7
4. Try to run the following F# snippet (supposedly supported by F# 4.7 as per the blog post here)

open System
type Customer =
    { Id: int; Name: string }
    member _.Code = _.Name + (string _.Id)

The same issue was observed when using the built-in FSI support in ionide-fsharp 4.1.0 and VS2019 16.3.1

Expected behavior

The code snippet above should be successfully interpreted.

Actual behavior

Getting error FS0010: Unexpected symbol '_' in expression, as shown on the screenshot below:

Known workarounds

None to date.

Related information

• Windows 10
• .Net Core SDK 3.0.100
• ionide-fsharp 4.1.0
• Visual Studio Professional 2019 16.3.1

[abelbraaksma]

I'm not 100% sure, but I thought the change in language semantics was that the single underscore was allowed as placeholder for the member declaration for cases where you don't need to access the class instance; but not as a self reference itself (like with _.Name). Just like you cannot access it when it is used in a function declaration as argument placeholder.

In other words, I think this error is expected. If you want to access the self identifier, use double underscore, or any other allowed identifier.

[Youenn-Bouglouan]

Hi @abelbraaksma , it was not allowed prior to F# 4.7, but if I understood the blog post here correctly, it is possible now. It is illustrated by the snippet below:

// Broke: F# 4.6 and lower
type C() =
    member __.M() = ()

// Woke and Bespoke: F# 4.7 and higher
type C'() =
    member _.M() = ()

Please note that I also tried various variations, like using single underscore on the left-hand of the equality and double underscore or 'this' on the right hand (and vice-versa), but none was working.

[TheJayMann]

It is correct that the purpose of allowing a single underscore as the self identifier was for cases where you are not going to use the self identifier. The same error message is also given for the following function definition.

let add1 _ = _ + 1;;

In the case above, as you are adding a method to a record and you are accessing the fields of the record, you need to have a self identifier which has a name, and the single underscore wildcard identifier is not named. The use of a double underscore works in your example because the double underscore is not the wildcard identifier, and, thus, has the name of __.

[BentTranberg]

The point of having the convention with double underscore was exactly to indicate that a self reference was not needed and not used. Using the double underscore for referencing self in the manner shown, is a breach of that convention. The compiler didn't catch that kind of misuse. After all, it was only a convention, so there was always the danger of someone misusing double underscore, potentially introducing hard to find issues. This has been dealt with in this latest version. The given snippet is indeed proof that the new syntax works. You are not allowed to use underscore for self reference, but must choose a name, thereby making it clear that you are using self reference. You don't have to read through the implementation to know whether self is (potentially) referenced or not.

[Youenn-Bouglouan]

Thank you @TheJayMann and @BentTranberg for your clarifications, I undertand where the problem comes from now. Indeed, the following snippet works just fine:

type Customer =
    { Id: int; Name: string }
    member _.Code = "CODE"

VS Code + Ionide still shows an error in the editor, but this is probably because the rules haven't been updated just yet. I haven't tried it in VS.

I believe I can close the issue.

[baronfel]

To close the loop, yes @Youenn-Bouglouan FCS/FSAC/Ionide need to be updated with these changes. That'll be happening this week.

[cartermp]

This can be seen as by design or as a bug, depending on your view of the following two function definitions:

let f __ = __ // Compiles: 'val f : __:'a -> 'a'
let f' _ = _ // Error: Unexpected symbol in '_' in binding

The behavior reported in this issue is consistent with the function definitions above. However, if the second function definition is seen as something that should work, then this would be a bug.

[Youenn-Bouglouan]

@cartermp this is exactly what confused me when reading the original post.