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

Allow expr[idx] as indexer/slicing syntax #1053

Closed
4 of 5 tasks
dsyme opened this issue Jul 27, 2021 · 4 comments
Closed
4 of 5 tasks

Allow expr[idx] as indexer/slicing syntax #1053

dsyme opened this issue Jul 27, 2021 · 4 comments

Comments

@dsyme
Copy link
Collaborator

dsyme commented Jul 27, 2021

F# has used expr.[idx] as indexing syntax. This was inherited from OCaml, which uses it for string indexing lookup. However in F# the notation has always been type-directed, so a well-known strong indexable type has been needed for expr.

Based on the experiment at dotnet/fsharp#11749 I propose we allow expr[idx] as indexer/slicing syntax and normalize this as the preferred indexing syntax from F# 6.0 onwards.

This is to make learning F# easier and allow simpler migration of existing code.

As with any indexing today known type information is required, e.g.

let f (arg: int[]) = arg[0], arg[1]

This is because

let f arg = arg[0]

exists today in F# and infers x to be a function x: int list -> 'a. In this case we woll give a deprecation warning on x[0] to say "please add a space indicating function application or a type annotation indicating indexing" i.e. let f arg = arg [0] for the former.

Technically this is not a breaking change to existing well-typed code (because we can use types to disambiguate between a function and something supporting indexing). However, as a matter of policy we will emit warnings to recommend small adjustments to existing code to properly disambiguate, by introducing spaces for function application. Informational recommendations to change expr.[idx] to expr[idx] will also be given.

I will put the details in an RFC

Extra information

Estimated cost (XS, S, M, L, XL, XXL): S

Related suggestions: (put links to related suggestions here)

Affidavit (please submit!)

Please tick this by placing a cross in the box:

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • This is not something which has obviously "already been decided" in previous versions of F#. actually it is and we're looking at it to ease language learning

Please tick all that apply:

  • This is not a breaking change to the F# language design. it's not a breaking change but we will use warnings to recommend small adjustments to existing code to properly disambiguate
  • I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

@dsyme dsyme changed the title Allow expr[idx] as slicing syntax Allow expr[idx] as indexer/slicing syntax Jul 27, 2021
@dsyme
Copy link
Collaborator Author

dsyme commented Jul 27, 2021

@amieres
Copy link

amieres commented Sep 7, 2021

This reminds me of another suggestion with the same motivation:

This is to make learning F# easier (less to learn) and allow simpler migration of existing code from Python, C# and other languages.

Maybe it is time to revisit: #644

Namely to allow f(parm) be equivalent to (f parm) as in c-like languages

@gusty
Copy link

gusty commented Oct 7, 2021

I agree with @amieres if both are breaking changes, I suffered more from having to add parens everywhere for stuff like (fn x()) and also saw how beginners got trapped into non obvious situations like f x(). I think we should deprecate it in order to change it in the future.

@dsyme
Copy link
Collaborator Author

dsyme commented Oct 13, 2021

Completed in F# 6

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

No branches or pull requests

3 participants