10-17-2022, 06:32 AM
Personally I do actually like this kind of syntax, C# has similar functionality via doing a
I will say that it has some downsides. It's a nice syntax in terms of being easy to read, but in my experience it makes it a bit harder to verify that all possible cases are actually covered (since the possible combinations quickly balloons).
Additionally IMO performance isn't a huge concern. A "good" compiler would be capable of optimizing this statement such that it doesn't matter how you write it. QB64 is not there, so certainly there's a potential performance penalty due to the likely multiple comparisons used to implement it, but IMO not enough to really matter anyway for most people. That is also something that could potentially be improved in the future sometime after the command is added.
That said, echoing what Steve said a bit, I can't pretend I have enough time to look at implementing something like this, I have too much I'm trying to get done already XD If someone was interested though I'd encourage them to submit a proposal on GitHub and we could talk about potential syntax and such (I don't think the syntax Pete gave would quite work).
switch()(equivalent of
SELECT CASE) on a 'tuple' value (which is basically just a variable that holds multiple other variables). You can then have cases like
case (> 0, < 20)where the first and second values in the tuple have to match those conditions. I've used it a few times and it makes it very easy to read the actual conditions you're checking for vs. having nested
switch()or a bunch of
ifstatements.
I will say that it has some downsides. It's a nice syntax in terms of being easy to read, but in my experience it makes it a bit harder to verify that all possible cases are actually covered (since the possible combinations quickly balloons).
Additionally IMO performance isn't a huge concern. A "good" compiler would be capable of optimizing this statement such that it doesn't matter how you write it. QB64 is not there, so certainly there's a potential performance penalty due to the likely multiple comparisons used to implement it, but IMO not enough to really matter anyway for most people. That is also something that could potentially be improved in the future sometime after the command is added.
That said, echoing what Steve said a bit, I can't pretend I have enough time to look at implementing something like this, I have too much I'm trying to get done already XD If someone was interested though I'd encourage them to submit a proposal on GitHub and we could talk about potential syntax and such (I don't think the syntax Pete gave would quite work).