Bikeshedding syntax: Appropriate to use square brackets?

[littledan]

In JavaScript, currently, [ ] consistently has the semantics of property access (not just array access). This proposal gives them a second usage, as a way to create slice, based on whether the contents of the brackets contains a colon. I think we should be careful about this--it might lead to confusion. I wonder if some other tokens might be more appropriate here, even though it'd be unfortunate to move away from the convention that we have from Python and CoffeeScript.

[dissimulate]

Python has the exact same situation, e.g:

a = { 'b': 1 }
a['b']

I think the concept of a[0] accessing the first index and a[0:3] accessing the first to third is very intuitive, and if it's a range then it follows that it would be a copy. It doesn't really read as two different functions. I'd suggest that using any token other than [] to denote indices would be much more confusing, it wouldn't be unknowing used given that it's an abstraction and currently invalid syntax.

[atticoos]

I see what you mean, but at the same time they both feel like they're doing the same thing: accessing properties of the subject

a = [0, 1, 2, 3]
a[1] -> 1
a[1..3] -> [1, 2, 3]

It feels that they intuitively share the same principles. One doesn't seem to conflate the other with a different semantic, even side-by-side.

The first accessor seems intuitive: Give me value at position 1
The second accessor does as well: Give me values inclusively between 1 and 3 (inclusivity and exclusivity, ofc, a separate topic)

[alexweej]

I came here to say the same thing. (Hi @littledan!)

I think something like Array.prototype.get (c.f. Map.prototype.get) is a less contentious way to provide these features. Then the parameter to .get can be some rich object expressing "from start", "from end", "slice [A, B)", "slice [C, D] with step E", etc. (Ab)using property lookup (constrained to strings and symbols) is not a good idea IMO.

[littledan]

Yeah to be clear I'm not really against using [ ], I just wanted to open a discussion on the issue. And I can't think of another kind of brackets that would actually make sense.

[lazeebee]

Maybe could change it to similar syntax like https://github.com/jfet97/tc39-proposal-dotstructuring

arr.[1:2];

[jugglinmike]

In addition to the overloading of square brackets, this proposal introduces an inconsistency in the interpretation of number values.

There's a strong conceptual link between arr[1:] and arr[1]. Where the former is "the second element and everything afterwards," the latter is just "the second element."

This doesn't hold for negative indices. arr[-1] has no relation to the proposed arr[-1:]. By supporting negative values, we'll be introducing a new abstraction which doesn't quite map to the one it's intended to mimic.

[alexweej]

Aside, the fact that negative indices have a conceptually different meaning ("from the end") leads to a hazard in Python whereby programs can have confusingly buggy behaviour when integer arithmetic is used to compute indices.

[hax]

@alex-weej Could you give some examples to help us to understand the hazard?

[alexweej]

anything that involves index computation ends up creating a 'reverse image' of the sequence if bounds checking is not done to 'null out' out of bounds lookups. the static type system won't help you because it's perfectly valid as far as the type system is concerned, and at runtime you only MIGHT get an IndexError if you happen to compute an index less than -len(sequence).

[caub]

Agreed on that concern, I think it could be good to borrow the hash syntax from tuple

arr#[0:5] // arr.slice(0, 5)

I think we could even go further that slice notation

For example, arr#[0:5] could be the same as arr#[0,1,2,3,4]. And similarly, arr#[2,4,0] would be [arr[2], arr[4], arr[0]]

[ljharb]

If it uses Tuple syntax, I’d expect it to produce a Tuple - but the goal is to produce an array.

[caub]

Fair point, yes it should return an array, not a tuple.
Maybe think of the # hash there as just syntax to disambiguate from the property access.
Also class private properties use a hash in their syntax, despite having no connection at all with records and tuples

[caub]

Similar idea than @lazeebee's arr.[1:2] above, but I think it could be good to avoid . here, even in the dotstructuring proposal you linked, because dot just strengthens the idea of property access, that's what optional chaining also uses: arr?.[1] for example.

So using another character, # or another is probably better

[alexweej]

Is it a given that we /need/ syntax for this? Until we introduce epochs or kill ASI or something we're rapidly running out of options.

array.get(new Slice(3, 23, 3))

Would be consistent with how we introduced other syntactical forms to the language for e.g. array and object literals. In the future sure we can have what new type of syntax we want

array.get(🍕<3, 23, 3>)

[stiff]

The biggest problem I see with overloading [] is that it normally returns element of list, while here it will change return type drastically, since range should be passable like any normal value. Something like array[[range]] == array[[1..5]], or object[['x'..'z']] would be nice, but it's obviously too ambiguous.