Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial proposal for language feature Continue For id and Exit For id #423

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

AdamSpeight2008
Copy link
Contributor

Initial proposal for language feature Continue For id and Exit For id

@DualBrain
Copy link

Interesting thought and it's hard for me to constructively argue against given that Next already has this (optional). Makes sense to me; it might even fall under the "it should have probably been done in the first place" category. @AdamSpeight2008 Out of curiosity, has anyone given any reason(s) as to why something like this doesn't make natural sense?

@AdamSpeight2008
Copy link
Contributor Author

AdamSpeight2008 commented May 4, 2019

@DualBrain Please note that I am not a member of the language design team or Microsoft, just a passionate external contributor.
Only thing I can find from the LDM 2017.12.06 Meeting is that they shouldn't have a list of control variables eg. Exit For y, x and Continue For y, x. The design as implemented does permit extending to named loops, by adjust the labels used within the lowering of the different loops. But I have not implemented named loops, as the VB LDM haven't made a decision on it yet

You are welcome to try out the prototype. (just the usual waivers, don't use on anything you not prepared to lose time and work on)

@AdamSpeight2008
Copy link
Contributor Author

@AnthonyDGreen Would you mind looking at this proposal?

Base automatically changed from master to main March 9, 2021 19:15
@DualBrain
Copy link

@KathleenDollard I know that this would technically be a "language change"; but it seems to be pretty low hanging fruit that addresses two clear issues:

  • Removes the need for an "ugly" goto.
  • Fills in what I believe is a bit of a gap with Exit For and Continue For given that Next does have this associated label.

It also appears that Adam may have most of the work completed; so, as a bonus, this could/would be a community contribution - a win in my book if it could be seriously considered.

As a side note, this conversation basically began to duplicate itself in another arena (a gitter conversation) and, more interestingly, completely unrelated to this entry in github even being known by those raising the question - so it does seem to have some legs as a general thought/improvement.

As I said before, I can't really argue against this being added since it does seem pretty clear that it is missing given what it is and what already exists.

Thanks for your consideration.

CC: @CyrusNajmabadi

@AdamSpeight2008
Copy link
Contributor Author

@DualBrain It only get rid of the goto from the users, code the lowering is still a goto
I'm not too sure about the quality of the code, as it is was a quick and dirty proof of concept. If I recall correctly it involved altering how we named the labels, used in the lowering of the for and for each. By extending them to include the loop's identifier used by said loop.

@DualBrain
Copy link

DualBrain commented Jun 29, 2021

@AdamSpeight2008 I don't see it being an issue that it is lowering to a goto; at the end of the day many of the constructs within the language are hiding the "ugliness" that is goto (to be clear, I'm not saying that goto is bad; it's just that we've got a few ways to write code that is cleaner, clearer and more understandable that hides jmp complexities). This is one of those proposals that I've seen that is really in that grey area between "new feature" and "fixing a shortcoming/gap in what was added" (aka "bug"). To take this a step further... this, to me, is a clear example of the pitfall that exists when something that is inspired by other languages is added to VB without taking a step back to consider the impact it will have on the overall language. To be clear, I'm a HUGE fan of Continue For (etc) and I am also just as guilty as anyone else in not thinking about/considering what else may be missing (impacted) by the addition of these way back when I suggested adding this in a blog post. This isn't to blame anyone for any misstep; the contrary. I also am a proponent for the fact that language design is hard and it is only with the benefit of hindsight that reviewing this at a later date exposes that something was missed. The question now, with the benefit of 20/20 hindsight, is whether or not we can get this addressed given the current restrictions at play?

@DualBrain
Copy link

And with all that said... if we can get approval for this as a community contribution... I'd love to participate in helping getting it across the finish line. ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants