Adopt ref in Core.Iterate.Next#7381
Conversation
zygoloid
added
proposal
zygoloid
force-pushed
the
proposal-adopt-ref-in-core-iterate-next
branch
from
31b3b88 to
58eaf5a
Compare
Also incorporate the description of `for` from carbon-language#1885 into the design, suitably updated.
zygoloid
force-pushed
the
proposal-adopt-ref-in-core-iterate-next
branch
from
58eaf5a to
5a31928
Compare
zygoloid
requested review from
KateGregory and
geoffromer
and removed request for
a team
github-actions
Bot
added
proposal rfc
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
zygoloid
left a comment
zygoloid
left a comment
There was a problem hiding this comment.
I have modernized the desugaring, bringing it not to the present but to a little bit into the future. Hopefully that's not too distracting and the intent is clear?
| { | ||
| let range:? auto = <range>; | ||
| var cursor: auto = range.(Iterate.NewCursor)(); | ||
| while (let .Some(<pattern>) = range.(Iterate.Next)(cursor)) { |
There was a problem hiding this comment.
I'm ambivalent about using if let in the desugaring when it's not proposed yet, and we don't even know what syntax we want (although I think I agree with your choice here). Does this solve any problems aside from making the code cleaner?
There was a problem hiding this comment.
I was trying to make this code ready for when we change the interface to be exttype-generic. Switched to a match to achieve this without using imaginary features :)
|
Argh, this collided with #7350, which was incorporating the old |
| ExecuteForBlock(iter.Get()); | ||
| iter = container.(Iterate.Next)(ref cursor); | ||
| { | ||
| let range:? auto = <range>; |
There was a problem hiding this comment.
I thought :? hadn't been through a proposal?
Should there be a TODO to more holistically revisit this with generics over extended types?
3 participants
Change the
cursorparameter inCore.Iterate.Nextto be arefparameterinstead of a pointer parameter.
Assisted-by: Gemini via Antigravity