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

Change default reported type annotation for arrays #635

Open
ReedCopsey opened this Issue Jan 10, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@ReedCopsey

ReedCopsey commented Jan 10, 2018

Change default reported type annotation for arrays

I propose we change F# lists reported type annotations to always use array instead of []. The existing default causes significant confusion, especially to people new to F#.

For example, the following output in FSI is incredibly confusing because it's apparently inconsistent to new users:

> let x = []
let y = [| |];;
val x : 'a list
val y : 'a []

While lists are declared using [ ], the type annotation shows list. Arrays, however, are declared using [| |], but the type annotation shows [], which "looks like an array" to new users. We very frequently get questions from people who are very confused when coming to F# because of this.

I propose to change type annotations which are reported (tooltips, FSI, intellisense) to display as this instead:

> let x = []
let y = [| |];;
val x : 'a list
val y : 'a array

Note that I am not suggesting changing or breaking compatibility. Using [] should still be allowed in manual type annotations. Today, you can easily use [] or array interchangeably. I am merely suggesting that all tooling should switch to suggesting array, as it'd be more in line with list, but also less confusing to new users.

Pros and Cons

The advantages of making this adjustment to F# are consistency for new users. Arrays would be obvious as arrays instead of being confused as lists.

The disadvantages of making this adjustment to F# are that it's a change from previous behavior.

Extra information

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

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#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

  • This is not a breaking change to the F# language design
  • I or my company would be willing to help implement and/or test this
@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Jan 10, 2018

backward compatibility aside, 💯 this.
if need to happen in F# 5.0 ok, but is really nice to have it scheduled.

parser need anyway to know that val y : 'a array is the same as val y : 'a [] so..

enricosada commented Jan 10, 2018

backward compatibility aside, 💯 this.
if need to happen in F# 5.0 ok, but is really nice to have it scheduled.

parser need anyway to know that val y : 'a array is the same as val y : 'a [] so..

@ReedCopsey

This comment has been minimized.

Show comment
Hide comment
@ReedCopsey

ReedCopsey Jan 10, 2018

Yes - I wasn't suggesting making any changes to parsing - merely to what gets reported by FSI/tooltips and other annotations in the language service/etc. This is a "change how the tooling reports" vs "change the language" suggestion.

ReedCopsey commented Jan 10, 2018

Yes - I wasn't suggesting making any changes to parsing - merely to what gets reported by FSI/tooltips and other annotations in the language service/etc. This is a "change how the tooling reports" vs "change the language" suggestion.

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Jan 10, 2018

i written that badly.
i mean any code out there should already known are equivalent, so is not a big breaking change.
like fsdn.azurewebsites.net for example who allow both signature
so good to have a new default for array signature

enricosada commented Jan 10, 2018

i written that badly.
i mean any code out there should already known are equivalent, so is not a big breaking change.
like fsdn.azurewebsites.net for example who allow both signature
so good to have a new default for array signature

@ReedCopsey

This comment has been minimized.

Show comment
Hide comment
@ReedCopsey

ReedCopsey Jan 10, 2018

Yes. It's likely that some tests which parse the output of FSI or tooling would likely fail, since they likely make the assumption that array will annotate as [], but actual production code should be completely backwards compatible.

ReedCopsey commented Jan 10, 2018

Yes. It's likely that some tests which parse the output of FSI or tooling would likely fail, since they likely make the assumption that array will annotate as [], but actual production code should be completely backwards compatible.

@realvictorprm

This comment has been minimized.

Show comment
Hide comment
@realvictorprm

realvictorprm Jan 11, 2018

Member

This is a small change with great effect for newcomers, thanks @ReedCopsey

Member

realvictorprm commented Jan 11, 2018

This is a small change with great effect for newcomers, thanks @ReedCopsey

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Jan 15, 2018

Also, you can already use array instead of [] syntax e.g. { Customers : Customer array } (which I actually happen to prefer) so this fits in anyway.

isaacabraham commented Jan 15, 2018

Also, you can already use array instead of [] syntax e.g. { Customers : Customer array } (which I actually happen to prefer) so this fits in anyway.

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