"land" reserved keyword error message

[jpeg729]

The error/warning messages for reserved keywords are inconsistent and sometimes very misleading. Notably those that are reserved because they are keywords in OCaml all produce the message "error FS0010: Unexpected infix operator in binding".

This confused me no end when I first saw it.

Repro steps

> let land = 3;;

  let land = 3;;
  ----^^^^

/home/user/stdin(1,5): error FS0010: Unexpected infix operator in binding

Expected behaviour

An error message that tells me not to use "land" as a variable name.

e.g. error FS0010: Unexpected keyword 'land' in binding

or maybe an error like the following warning warning FS0046: The identifier 'fori' is reserved for future use by F#

Actual behaviour

The compiler complains about an infix operator. I assume that the compiler is confused by the equals sign between the reserved keyword and the value.

Related information

• #1103

[cartermp]

I think this is actually a bug, as it should be allowed but with a warning. Here's what it is with trait:

Microsoft (R) F# Interactive version 10.4.0 for F# 4.6
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> let trait = 3;;

  let trait = 3;;
  ----^^^^^

/Users/phillip/repos/FSharpx.Collections/stdin(1,5): warning FS0046: The identifier 'trait' is reserved for future use by F#

val trait : int = 3

[dsyme]

In F# 5.x we should just remove the reservation of very old OCaml-comapt operators land, lor, lxor`. We don't need them in any F# code.

[reinux]

Somewhat related question: is params ever going to be used? Could the warning be made context-aware the way value is in C#? I'm probably not alone in finding myself wanting to name things params pretty often.

[cartermp]

@reinux as a general principle we want to avoid context-sensitive keywords as much as possible. I'd defer to @dsyme on this particular case for deprecating params as a reserved future keyword, but context sensitivity isn't something we'd pursue.

[dsyme]

I'm probably not alone in finding myself wanting to name things params pretty often.

Yes we should remove this