Swift Loop In 3ds Max

[Map Rousch]

Ihad a slightly different pitch some time ago where I wanted a single where clause to combine multiple cases. Now the example from @ole makes me thinking if it would also make some sense in a for loop, although they already can have where causes at the end.

I still have a hard time wrapping my head around the case let construct. Maybe it's just because as words they don't make much sense together, but it's just not obvious to me how it works and every time I look it up I forget it soon after...

Yeah, if case and for case constructs always end up deeply unsatisfying to me. They make some sort of sense if you just imagine them as a case label inside a switch over whatever sits on the right-hand side of the =, but it always requires me to look up the syntax as well.

Patterns, i.e. the conditions you write in a case clause of a switch statement, are a universal feature of Swift that's used in tons of places: switch, if and guard, for and while loops, catch clauses. Even in a plain assignment such as let x = 1, the token x is an identifier pattern.

for loops don't support multiple consecutive patterns (e.g. separated by commas, as in if or guard statements), so it's not possible to express this directly in a for loop. @MasasaM has shown two viable alternatives that solve this by changing the sequence that's passed into the loop.

I'll note that we are in Discussion, so we're not limited by what's currently possible . Allowing pattern bindings in the where clause would IMO read much more cleanly than the lazy.compactMap version, or any of the case let alternatives proposed.

A downside I can see is that it would then suggest that where clauses in switch statements should also support pattern bindings, which seems redundant since you can also bind patterns in the case expression immediately preceding the where. So we'd either have to separate these two forms of where, or allow pattern binding to happen in two places in the case statements.

I think, as many do, that this could be better. It's rather strange to see a = there, because that's not an assignment. The other problem, here, is that the value is spelled after the case statement, which means that, to get proper autocompletion and everything, you should write first

If, after reviewing these links, you feel like there's a new direction or perspective to be had on the topic, then by all means please do share! In that case, it can be helpful for the community if you'd write a short synopsis of what you learn from these readings so that we're not starting back at square one.

If this solution were not built-in to Swift, it would have the issue of scalability (has to be written many times, perhaps once per app, or once per engineering group), and potential for incorrectness (range logic is easy to get wrong), and confusion. (Why are we creating a variable we don't need? Isn't that a bad practice? Is there a better way?)

The fact that people in this thread wonder whether you meant to do this 9 times or 10 times is great evidence of the unnecessary risk of this solution. Ranges are easy to get wrong. Extensions don't scale well for reasons listed above. Extensions also aren't available in all environments (e.g. online Swift learning, interviews, leetcode, etc). An extension on an integer is perhaps a little unintuitive. I don't consider repetition a property or functionality of an integer.

If you dropped the repeat, it's similar to solution 1. Building a new function into Swift is an alternative to adding a new keyword/language feature. I don't have a terribly strong preference on which way to go.

a) I'll create a list of N elements

b) What type should that be? Can I provide any sensible type?

c) I guess void works.

d) What about warnings from unused variables?

e) I guess I'll use the underscore

f) Is there a better way? Best practice is to avoid unused/discarded variables in the first place.

g) No, there isn't. (Perhaps we should add this language feature to Swift some day.)

h) Ok, let's just go with this.

Regarding 2, I don't consider this a major issue as it's a very simple concept to understand. Any engineer who wishes not to learn it can simply use other ways. Anyone who comes across it for the first time can easily guess what it does.

The advantages of for N are clear. Simplicity is priceless in software engineering. Simplicity avoids the risk of bugs and makes it easier to solve hard problems. I also argue it's more enjoyable to write for N than for _ in 0..

At the end of the day I like for because I've been coding in C or the languages that took inspiration from C (Swift included) for nearly 20 years. for someone used to for, for is just easy to remember. I do consider repeat and for about equally good and would be happy with either.

One important thing a little beyond the syntax, would be the reason we want to repeat something n times. Why specifically n, a magic number, sufficiently large number, to allocate space for some collection? Because well, it won't matter how many times you repeat something for sufficiently large number and the problem with off-by-one error greatly diminished. Matching the collection is probably much quicker, and more concise with

This ask is not coming from a "magic number" place. I've commonly come across this need while solving hard problems (i.e. harder than iterating a collection). The number is typically derived from math based on the input size or nature of the input.

Having an underscore in the code is a code/language smell to me. Not because it's unaesthetic, rather because it highlights that the language expects us to need a variable in the following scope, yet we do not.

That's my point. This feature does not add any expressivity. It's dead-simple to implement. It doesn't add any composition to the existing features. The only strength would be the frequency this comes up, and I'm calling that into question.

Please read the above thread to see a discussion of the benefits of my proposal and the downsides of the other options. The existing options in Swift are less simple than what I'm proposing. What I'm proposing does remove a potential class of bugs.

Regarding quantification, have all past Swift evolution proposals been based on quantifiable data? Do we have datasets showing statistically significant Swift engineer usage of the language? If so, I'd be happy to quantify this for you. If not, perhaps we can still make a decision in the absence of quantity.

As you can see, compressionCount is not a magic number. It's the number of times a substring repeated prior to being compressed. Repetition in this case is not on a sequence, rather it has to happen that number of times.

Yes, it does. I'm not arguing with that. It removes any potential off-by-one if you are repeating things, exactly n times. It doesn't go much beyond that though. I can't use this with things like firstOffset and lastOffset, not neatly.

Your syntax fixes a very specific class of off-by-one error, while leaving other classes intact. It's even more dangerous considering that off-by-one error can still appear in your syntax which is boasting to be free of (other) similar bugs.

Hmm, actually, it's more of a sufficiently large number case. Since many numerical algorithms I have in mind are something akin to keeps repeating, the stopping condition will be met within n cycle, and somehow got mistranslated to keeps repeating for n cycle. Anyhow, there's no point in going specific, we're really starting to play your-anecdote-my-anecdote here. My bad...

One contrasting point of view from this thread in comparison to past threads is that repeat N or for N is not just for beginners. Other threads characterize repeat N as a language feature primarily or only useful for teaching or beginners. I actually come across a need for this feature most commonly while solving moderately difficult to very difficult algorithms.

There seems to be almost a macho trend amongst the prior threads, that we're all experts and therefore won't mess up ranges. As someone who interviews candidates frequently, I can tell you off by one errors are outstandingly common, even among programmers who are among the best in the world.

Chris Lattner mentioned the only reason Swift doesn't already have repeat N is due to resourcing. I don't see anything in those threads that seems definitive that Swift does not need this. What's stopping us from adding this?

That's not quite how this process works. The question, rather, is whether there's anything which shows definitively that Swift needs this. Syntactic sugar has been among the lowest of all priorities in Swift Evolution, to the point of being actively discouraged, so the bar for justifying such a change is extremely high.

If you have a catalog of algorithms where you've needed this feature, feel free to share those here. Likewise, if you can show that Swift code in the wild has been buggy because of looping an incorrect number of times, that would be useful information. But repeating what has already been said another time would not clear that bar.

Hi - I've just recently switched to max 2021 and am having some problems with swift loop feature I would really like to understand and solve if possible

1) Swift loop now works on hidden elements of the mesh. See first image

Is it possible to disable this?

When working on complex meshes I hide parts that are in the way of modeling or are making things hard to see. This would allow me to insert or remove loops from parts I'm currently focusing on. But now it seems that even if I hide a part of the mesh "swift loop" detects it. Meaning I would need to detach it so I can work on the rest of the mesh. It is extremely annoying and makes my workflow significantly slower

3a8082e126