[RFC FS-1110 Discussion] Allow expr[idx] for index/slicing

[dsyme]

Discussion thread for https://github.com/fsharp/fslang-design/blob/main/preview/FS-1110-index-syntax.md

[no1melman]

I personally don't think it will make that much of a difference, coming from C# it doesn't really trip me up or is big enough to create barrier. I've not even had anyone bat an eyelid at the difference.

Once you accept the difference between , meaning in F# and the nuances of parenthesis, .[] is just insignificant.

WRT porting code, I think that F# is enough of a different syntax that you wouldn't gain much, a simple replace regex could help turn something[] into something.[]. /[a-zA-Z]\[ off the top of my head

[londospark]

I quite like the .[] syntax as it reminds you that indexing is a property access that can include code rather than syntactic sugar for pointer arithmetic as in C/C++. The current syntax therefore feels more logical and consistent to me even if it doesn't match what other languages use.

[HoraceGonzalez]

I'm sure python programmers would appreciate one -- and preferably only one -- obvious way of doing this.

[Shredderroy]

There is no reason to do this. Python does nothing to accommodate F# programmers, so I don't see any need for F# to extend such a courtesy to Python programmers. I cannot imagine that the addition of this method of indexing is going to convert even a single Python programmer to F#.

[dsyme]

I cannot imagine that the addition of this method of indexing is going to convert even a single Python programmer to F#.

I think you under-estimate the importance of syntax differences in the minds of people.

When you compare machine learning code in Python with F#, this absolutely stands out. Two of the most experienced researcher/architect/programmers I know have repeatedly asked me about this specific point. Again. And Again. And Again. They don't let go.

[matthewcrews]

As someone who made that transition, this indexing notation was one of the BIG hangups. You develop a lot of muscle memory and needing to remember . adds a lot of friction.

[Shredderroy]

That is news to me. My primary, i.e., most utilised, programming languages are Wolfram Language, F#, and Python, and all three of them have different syntaxes for indexing arrays. (Wolfram Language uses double square brackets, arr[[idx]].) And I have never felt particularly inconvenienced by the differences.

Programming is less about reproducing actions from muscle memory, and more about expressing the structural elements of the problem and their interrelationships elegantly. As long as F# and Python continue to prefer very different idioms for expressing those relationships, I can see only a limited benefit in making a small change in one small corner of one of the languages, Syme's anecdotal evidence notwithstanding.

[dsyme]

Feedback from Niklas at Microsoft

[cartermp]

Hugely in favor of doing this and more than happy to delete the code fixer in VS tooling for it.

I think the thing that sucks the most about the current experience is that there's no way in tools to know that after you typed the . you don't want a completion list. So annoying, since my mind is trained to always focus on that completion list whenever I hit . in any other context.

[cartermp]

I don't follow. Let's say I have an array and I type . on it, but I do not want to see a completion list because I'm actually interested in indexing.

What should happen?

[heronbpv]

First item in the list is the indexer, then write the [ and ] when selected.

[cartermp]

Gotcha. So there's a two options here:

Create a separate, synthesized completion item made up of some symbols

The type on the LHS needs to have an Item member on it for this to appear. This opens up some questions though:

• What should the item in the list be?
• Where in the completion list should this completion item be? Symbols typically come first, but this isn't a real symbol -- it's a synthesizes item.
• What should the tooltip that comes up when you select it be?
• What is the behavior when you commit this completion item? Should the cursor be places in between the brackets?

Bring Item into scope for the completion list

Instead of synthesizing a new one, any type that implements Item as a member will now have Item brought into the completion list. Similar questions, though:

• Since it's not a symbol, it would show up alphanumerically in the middle of the list. Is that okay?
• What should the tooltip that comes up when you select it be?
• What is the behavior when you commit Item? Should the cursor be places in between the brackets?
• You cannot write a.Item today. Should that also be allowed and/or be the default instead of a symbolic thing when you commit the completion item?

Frankly I think it's a lot simpler to just have a[idx] by the default behavior than do one of these.

[heronbpv]

I suppose you refer to the text in the suggestion list, right? If so, "[idx]" or similar, potentially showcasing the index parameter type (string, int, etc.) on the side. If a type has a Item member defined, transform the text on the list to my suggestion and order it as normal. If this is the option selected, put the caret between the brackets.
From what I can see, at least on Rider 2021.1.5, Item is both suggested and can be accessed as normal:

//Put this on a fsx file
type Test() =
    member p.Item
        with get(organ) = //match clause from the book Professional F# 2.0, p. 137
            match organ with
            | "Heart" -> "Ba-dump"
            | "Stomach" -> "Growl"
            | "Mouth" -> "Chomp chomp swallow"
            | "Brain" -> "Crackle crackle"
            | _ -> ""

let t = Test()

t.["Heart"]
t.Item("Heart") //This works in netcoreapp3.1 at least

Frankly I think it's a lot simpler to just have a[idx] by the default behavior than do one of these.

Isn't it better to simply not have this work at all and leave things as is?

[cartermp]

Item is both suggested and can be accessed as normal

Not for arrays (2d, 3d, etc.). You could argue that should be "fixed" (assuming it's broken).

I would argue that every instance of Item should be invisible in completion lists though, since the signature is confusing (property that accepts an argument!).

Isn't it better to simply not have this work at all and leave things as is?

No.

[dsyme]

I cannot imagine that the addition of this method of indexing is going to convert even a single Python programmer to F#.

I think this under-estimate the importance of syntax differences in the minds of people.

When you compare machine learning code in Python with F#, this absolutely stands out. Likewise code from C#/Julia/Java/C++. Two of the most experienced researcher/architect/programmers I know have repeatedly asked me about this specific point. Again. And Again. And Again. They don't let go.

[daniellittledev]

The expr.[idx] syntax did trip me up the first time I tried it (coming from C#) but I haven't had much of an issue with it since. I also tend to use the list functions like head, filter and map a lot, while not using indexing all that much.

Having said all that I think requiring the space to disambiguate between an argument and an indexer is pretty clear and I do think it would remove a bit of friction when first learning the language.

[migueldeicaza]

Oh god yes, please. Please, yes.

i am ecstatic just thinking about it - great early Xmas present

[brettrowberry]

I’m in favor.

[daz10000]

Please do it - I always assumed there were technical reasons for the dot being there. It's just an unnecessary mental hurdle for someone keen to write their first code. You get over it, but it's friction and you can better use the learning curve time on something that's a genuine language difference.

[dsyme]

I mean there are reasons, specifically the subtlety of

thing [1]

v.

thing[1]

But I think this is ok in balance with typical IDE support, code highlight tools and so on

[paudirac]

IMHO, it is nice also to use the space as a syntax disambiguation mechanism. (And is easier to type 😄.) Feels natural to see thing [4] [2] as a similar call than other 4 2 and another[42] as something else. I definitely have to think twice to parse that [4][2] as that [4] [2]. But I'm probably biased.

[peterzeller]

I kind of like the Scala way, where function application and array lookup have the same syntax. I guess that would be more difficult to do for F# due to type inference, so probably not an option.

Imho, ar[i] is much nicer than ar.[i], but ar i would be the best.

[JordanMarr]

Pros:

• I very much prefer the no-dot style after years of C# and JS, so the dot feels like extra baggage.
• I like to delete things.
• Making Python users happy is good for F# adoption which makes this a very easy yes for me.

Cons:

• There will be two different ways of doing the same thing.

[NiklasGustafsson]

I don't think of this as accommodating Python or attracting its users. I just want beautiful code. .[] is a wart, IMO.

Indexing looks like expr[idx] or expr(idx) in every single other language I can think of.

So, in my mind, it's just about aesthetics, simply, and aesthetics matter. I don't think anyone will be persuaded to use F# because of this, but if every time I have to say expr.[idx] I find myself grimacing, then over time I will think less of the language than I would otherwise.

This plus support for implicit conversion operators will make F# a far better language for numeric code. Aesthetically, that is. Functionally, it already is great.

[daz10000]

F# has a healthy history of embracing change and evolving (the whole light syntax was an experiment once upon a time). We have good tooling for upgrading code, I definitely agree on wanting beautiful code, not forever ridigity

[geodanila]

I constantly switch between different programming languages and the F# indexer syntax has never bothered me.

[dbrattli]

This is a really great idea! 😍 F# can be harder for experienced programmers (needing to unlearn this muscle reflex). There should imo be a very good reason for the . syntax, having it different from any other language, or we should just keep the same syntax as the others. The two things that annoyed me starting with F# was x.[y] and semicolons in lists [1; 2; 3] but as a Python programmer, the latter blew my mind when I understood that you could have yielding expression inside (and even remove the ; with multiline). The extra . for index lookup did not hide any super-powers.

[IltaySaeedi]

This is great. I think doing in two ways in the same file is also fine. It is good to be flexible and reduce the unnecassary gap between languages and devs.

[dpraimeyuu]

Great idea! This might be one of the initial steps to increase the conversion rate from Python-based Machine Learning/Data Science/Deep Learning to F#/.NET-based :-)

The journey of a thousand miles begins with one step.
Lao Tzu

[En3Tho]

I'm against this. It feels like an unnecessary syntactic sugar over 1 character. Like implicit yield was a feature that could save up lots of characters not to mention nice look and feel. But this is simply something that new programmers have to learn. Honestly it's just a dot.

[Lanayx]

I totally support this small sacrifice to make language more attractive for newcomers.
However this should also come with new warning - f[0] should require space if f isn't a collection

[JordanMarr]

The RFC does include some examples of this warning to add a space if f is determined to be a function. 👍

[MecuSorin]

I would like very much the change (not having the dot), main reason less noise. I see this change as good thing for the F#, not as a tool to attract other developers that know other languages.
The only drawback will be that new F# programmers will not realize that behind that syntax can be a custom function call (indexed property)

[snuup]

F# is my main language, say 80%. When I come back from js, ts, c# or else and quickly write an f# script I often forget the .[] . No big deal, but the proposed change here aligns syntaxes across languages which I find practical and also a nice and open attitude of language design.

Yes, pleeease.

[zyzhu]

I like the efforts to bring F# closer to widely accepted code conventions to ease onboarding of newcomers. However, I'm more stumbled upon two other syntaxes than .[].

In F#, ; is used to create arrays or list. In Python/R/MATLAB/TS, , is used. I still keep typing the wrong key after 7 years of coding F#.

Another one is [||]. The extra | is not there in Python/R/MATLAB/TS.

My point is that unfortunately we will never get there to please coders from different background completely. But I hope every bit of effort helps.

[Richiban]

While I appreciate the efforts in getting F# to more closely match other languages, what does this mean for calling functions and passing lists as arguments? TBH I see two possibilities and neither of them are great:

(1)

let x = dict ([1, "one"; 2, "two"]) // Parens are now required

(2)

let x = f [1] // This is calling a function, passing in a list
let y = g[1] // This is indexing

I think the difference between the two syntaxes in (2) is too small, so I wouldn't go for that (I also don't believe there are any other places in F# where a single space like that would change the syntax of an expression) but then having to add brackets to function calls as in (1) would really suck.

Not sure I like this

[JordanMarr]

(I also don't believe there are any other places in F# where a single space like that would change the syntax of an expression)

One existing scenario where a single space makes a difference is the binary - operator:

"
In summary, it's important to always:

Surround binary operators with white space
Never have trailing white space after a unary operator
The binary arithmetic operator guideline is especially important. Failing to surround a binary - operator, when combined with certain formatting choices, could lead to interpreting it as a unary -.
"

https://docs.microsoft.com/en-us/dotnet/fsharp/style-guide/formatting

[dsyme]

@Richiban - It means (2), with warning to update

[davedawkins]

Great idea. One less trip hazard for new users, and rewards those who use their intuition (based on other languages, granted) to figure out indexing syntax.

[chkn]

I don't think this is a good idea, for a few reasons:

1. This is a fairly disruptive change to the language. Deprecating the old syntax with a warning is basically forcing all existing codebases to change, to be trapped on --langversion:5.0, to add nowarn, or to disable warnings as errors and be stuck with a build warning-- none of which are very nice options.

2. This also affects function invocations where there is no space before a list argument-- admittedly it's probably less common, but still existing code that will now incur a warning. Anecdotally, I actually had a case in my code that came up just the other day where leaving out the space was more readable for a particular function.

3. The RFC states: There are some exceptions where the use of .[ will still be required -- this will only serve to make the matter confusing for everyone, in addition to newbies!

4. The current syntax foo.[idx] would enable a nice shorthand _.[idx] with Allow _.Property shorthand for accessor functions fslang-suggestions#506

TL;DR- I don't believe the stated motivation justifies such a disruptive change. However, I'd support the addition of the foo[idx] syntax without adding any warnings that can break existing code.

Alternatively, to make the current syntax more discoverable, we could simply add some helpful text to the error shown when foo[idx] is used incorrectly, and IDE tooling could suggest a code fix.

[dsyme]

@chkn

Anecdotally, I actually had a case in my code that came up just the other day where leaving out the space was more readable for a particular function.

Could you list out the case please? thanks!

[dsyme]

Deprecating the old syntax with a warning is basically forcing ..

My expectation is there would be an informational message on expr.[idx] initially (once the feature is out of preview). This could be disabled with --nowarn:NNN . Informational messages are very light in the IDE and don't fail the build if --warnaserror is selected (unless the specific --warnaserror:NNN is given.

The current syntax foo.[idx] would enable a nice shorthand...

I guess we would enable _[idx] as the shorthand - at first thought I don't see why not. (As an aside, there are also other related possible features, e.g. { expr with SomeCollection[3] = "abc" } for indexed functional update of a collection-valued property of a record)

[chkn]

Informational messages are very light in the IDE and don't fail the build if --warnaserror is selected (unless the specific --warnaserror:NNN is given.

This sounds fairly reasonable. But the implication is still that "one day" the old syntax will be removed, which still seems like an unnecessary abrasion to existing codebases.

As an aside, there are also other related possible features, e.g. { expr with SomeCollection[3] = "abc" } for indexed functional update of a collection-valued property of a record)

Personally, I think it would be more elegant to keep foo.[idx] as a first class alternate syntax and then enable generalized member updates, e.g. { expr with SomeCollection.Foo = "abc" } (and .[idx] is just another member like .Foo)

Could you list out the case please? thanks!

Sure! It's an active pattern used for special case handling of specific patterns of children in a hierarchy. Each child could potentially be expensive to compute, so there is some background state that is maintained for caching to ensure each invocation of the active pattern only computes the child once. The framework needs to know the index of the child (or grandchild, etc) to make that work. Example pseudo code:

match expr with

// match some special cases...
| Container("parent", [ Child[0](Elem "first child"); Child[1](Elem "second child") ]) -> // ...
| Container("parent", [ Child[0](Container("first child", [ Child[0; 0](Elem "first grandchild of first child") ])) ]) -> // ...
// ---------------------------^ Same index as previous line, so the child is looked up from the cache instead of recomputed.

| _ -> // handle the general case

Maybe there is a better way to accomplish this, but I was very grateful to F#'s flexibility to do that, and it would be a bummer to take away some of that flexibility and force spaces in there, as those match lines are already pretty long 😛

[vzarytovskii]

I think this would be great, especially for new programmers, who are just learning F#.

[matthewcrews]

I'm all for this provided that there is no loss of functionality. I use many overloads for index/slicing in Flips which you can see here.

This would ease the migration of people writing Mathematical Planning models from Python to Flips. The MP domain uses index/slicing heavily.

[awf]

As someone said, this is a wart. I read that statement as intentionally ambiguous: do I mean that .[ is a wart, or that the fix is a wart? I mean the former, the user-visible oddity. The fix is a wart only to those who deeply understand the language and its compilation;

Every time I show F# code to machine learning/computer vision folks, I find myself saying "yes, .[ for indexing is a wart, but every language has some warts". It really is every time, and every time, someone in the audience chooses this moment to say to themselves "this is a language I don't need to learn", drop their eyes to their email, and they are lost to us.

It's not a case of pandering to pythonistas, or mollifying matlabbers, or soothing C/C#ers -- the F# programmers I care about are not those who use it today, but the many many more people (we hope) who use it in the future. We should welcome those new joiners, and until everyone's first language is F#, we should meet their expectations where we can.

[awf]

I've tried both ways: just skate over it, and call it out. The former invariably invites a question from the audience, which then opens a discussion as to why, and ultimately proves more distracting.

No-one is saying "this patch is the key change that will draw programmers to F#". That would indeed be a pipedream. What I'm hearing is "this patch reduces friction for potential new lovers of F#"

[heronbpv]

I never said that this change will convince anyone to come (straw man), but it would certainly reduce friction that could cause someone to prematurely give up.

To say that “they are clearly not interested”… how do you know what they are interested in? Maybe “they” are sick of runtime errors and want a nice IDE experience.

Fair enough. Though I wouldn't call this change a improvement, considering the cruft the warning alone will cause to all code bases that already exist, it's clear our opinions diverge.
As to how I know? Because, if that's what you're selling them (maybe pitching is a better word?), and they reason that a dot to access a index is enough for a bail out, than I bet they have all the problems in the world, but runtime erros or IDE shortcomings. It's certainly the problem that brought me in (and you, perhaps?), so whatever language shenanigans may exists seemed like a small price to pay.
And just for clarity's sake, Awf, have you tried using the "because it's a member accessor" as an explanation? This shows consistency in the language, since indexers are themselves members of a type, and all type members are available through the '.' operator.
To make my point across, this change brings unneeded cruft for current language users, is going to introduce ambiguity to things that were previously clearer, and all in the name of being "nice", even though it's very likely the people bailing out on this will just find another reason to do so. That's how inertia works.

[awf]

Awf, have you tried using the "because it's a member accessor" as an explanation?

Yes, that's exactly the kind of distracting tangent that alienates the rest of the audience, so I prefer to avoid it.

...unneeded cruft for current language users...
...introduce ambiguity to things that were previously clearer...

Yes, no-one disputes that current F# users don't need this change. But we believe (or at least I believe) that F# could benefit an order of magnitude more users than today. So, for me, future language users have higher weight than current language users.

[awf]

That's how inertia works.

I think there are two forces in action here, let's call them "attraction" and "inertia". Attraction is what makes me want to try something new. Inertia is the force that makes me stick to what I know.

I imagine the conversation in audience members' heads:
A: look! F# offers us beautiful async, file handling, automatic differentiation, units of measure, ...
I: yes, but if we learn that, we'll be forced to stop using what we know
A: no, we can just learn this on the side
I: I know you; you say "on the side", but next thing it's all F# this F# that, and we're at a conference, and then we'll get behind on our real work, and then we'll be destitute, and it's all your fault
A: No, this will make us so productive we'll be able to do more. We won't port anything, just look at it for some new stuff.
I: But then we.... hang on, look! look at that horrible wart! on the slide! EWW.
A: But.. ok, maybe you're right.

[heronbpv]

Yes, that's exactly the kind of distracting tangent that alienates the rest of the audience, so I prefer to avoid it.

Hmmm, I can only wonder how explaining the why of a feature can be a distracting tangent, that aside:

Yes, no-one disputes that current F# users don't need this change. But we believe (or at least I believe) that F# could benefit an order of magnitude more users than today. So, for me, future language users have higher weight than current language users.

I don't think throwing cruft at the current user base is such a good move, even more so for the sake of an "order of magnitude more users" target that may never be reached.

As per the dialog, it proves my point: if that's the reason they'll abandon boat, then they aren't facing the same challenges as people who did. Even better, they'll find another reason to justify such a stance, and keep doing so because they see no point.