Closed usaoc closed 8 months ago
I'm not sure about this direction. I appreciate the issue with parsing (#349), but I'm leery of over-using function-call syntax in Rhombus generally. Also, while of_length
reads well, we've so far used "of" only for annotation constructors, and that seems like a useful convention.
I don’t know what’s the better choice—we only have so many kinds of brackets. I find this choice fine due to the parallel to the annotation form, but maybe someone will have a better idea.
In working toward #455, I ran into confusion with for Array ~length sizes.length()
when modifying with a for
that was already written with each
. So, I lean more in favor of this change than I did before. I still worry about the "of" convention, but having Array.of_length
also be an annotation constructor (as in the latest version) seems like a good step.
Is there any further objection to this from someone else? If not, I’ll merge this later.
Since this will break existing programs, let's wait just a little to combine with other breaking changes.
Rebased in https://github.com/mflatt/rhombus-prototype/tree/array-of-length. If if looks like I got that right, we can reset this PR's branch to that commit.
Mainly to replace the
~length
form ofArray
. My rationale is that reducer macros should consume a finite number of terms in the presence of theeach
shorthand; the existing parsing hack makes me very uncomfortable. Having a grouping in hand also makes it possible to add a~fill
option, as infor/vector
.