(Replying to PARENT post)
Chaining ?[] sucks no matter what you do, and as for parser ambiguity, my guess is that if the parser doesn't know how to understand an expression, then the best thing is to have it fail and ask the programmer to add parenthesis. Because chances are it won't make any sense to a human as well.
(Replying to PARENT post)
> someJson?[recipes]?[2]?[ingredients]?[pepper]
> To our eyes, that doesn’t look very good. It scans less like a method chain and more like some combination of infix operators — a little like ??. Compare it to this code:
> someJson?.[recipes]?.[2]?.[ingredients]?.[pepper]
Yep. So in the end ?[] does not look better, and the dot avoids the ambiguity with ? [] :
There you go. Dot. You could also allow `a.[x]` as a valid alternative to a[x]
(Replying to PARENT post)
Option.map (fun l -> Array.nth l n) your_optional_list
And why would anybody want a nullable collection or a special syntax for 'em, when any collection is already nullable, and an empty list or array is basically the same thing as None/Null?
(Replying to PARENT post)
(Replying to PARENT post)
I'm not familiar with Dart but I believe the same applies to all the C-derived syntax languages; predecrement vs subtraction of negation. If I remember correctly, the C standard even has "a+++++b" as an example (which is a syntax error, since it parses as "a++ ++ +b", but "a++ + ++b" would not be.)
As a "completely uninformed outside" opinion, how about not adding another operator, but automatically choosing based on whether the type on the left is nullable? I feel like there's already a lot of "implicit nullness" going around with this sort of language design, such that these operators are redundancy overhead --- and according to the article, the declaration of the type already tells you whether it's nullable.
(Replying to PARENT post)
Is similar to the syntax for the ! operator: e1
a?[b]
(Replying to PARENT post)
(The feature that conflicts, array literals, are using the obviously desirable syntax as well. This is just good intentions and path dependence in action.)
(Replying to PARENT post)
Not meant to be a dig - just forgot it existed.
As to the topic - a single question mark seems to make more sense.
(Replying to PARENT post)
I think that wins in terms of readability. Also, every Android developer is already used to that syntax.
I hope Google at some point opens up Flutter to other languages. IMHO it's being held back by Dart at this point and they are barking up the wrong tree by not addressing that directly. People are reluctant to switch to it because they have to switch language to something less nice. The solution is not flogging the dead horse that is Dart by slowly adding bits of features that they hope will bridge the gap.
Kotlin now has a native compiler and reengineering Flutter to play nice with the LLVM ecosystem would also enable other languages. Like Swift, Rust or C++. Also, WASM is becoming a thing in the LLVM world. A Flutter evolution that properly integrated into that eco system would be quite a useful thing to have.