There is more difference between “guard” and “ensure”. “Guarding” is something you do at the gate, not just everywhere. This has imo an impact on how code is structured. (It did for me) “Ensuring” is something you can do everywhere. Myself, I tend to use “guard” mostly at the beginning of a routine. Further in I tend to use “if’s” unless I need to define a variable for subsequent use and want to avoid nesting.
Rien. PS: non native…. PPS: No opinion on either changing or keeping guard > On 25 Oct 2016, at 20:44, Jay Abbott via swift-evolution > <[email protected]> wrote: > > Hey Joe, > > I tend to agree, it seems like a tiny niggle for experienced C-family > developers who have used if(negative condition) as a guard for years, and > those with knowledge in other languages where it is already known. But for > new developers, learning the language of the future as a first-language (such > as my other half, who is learning Swift as her first programming language > with the "Swift Playgrounds" app), doesn't it make sense for such a concept > to fit right in with their existing linguistic model of the world? This makes > a language intuitive rather than something you need to 'learn'. > > This is where "strong motivation" and "overwhelming evidence" lose their > meanings (to me). This group does seem to be strongly motivated to help new > developers, and ensure Swift is easy and intuitive for them, as well as > powerful for experienced developers. Is it practical to gather evidence on > how new developers learn and internalise "guard" or any other part of the > language? Probably not, so how can we ever have "overwhelming evidence" for > anything related to intuitiveness for new developers? Also is there a grey > area for source-breaking changes? I mean obviously a change is either > breaking or it's not, but if we were to take Marco's idea and use "guard:" > instead of "ensure" - existing articles and QA online would still be > searchable/relevant, the compiler could emit a fixme error to add the colon > when it came across old syntax (or Xcode's converter or a simple project-wide > search/replace would rectify old syntax), etc. so there are breaking changes, > and then there are trivial-to-rectify breaking changes. Another point is: If > there is a single breaking change, for strong reasons, doesn't that > invalidate all arguments against other (automatically convertible) breaking > changes which have not-so-strong reasons? If code needs to be converted, then > what difference does it make how many trivial automated changes there are? > And isn't that the entire point of a major version bump anyway? > > I think as a group we should be cautious of: > * hard/fast/unbreakable rules > * subjective terms like "strong motivation" and even "overwhelming evidence", > especially where our evidence is our own arguments and examples, as made and > interpreted by some of the experienced to genius level developers on this > list. > * denying or failing to recognise grey areas. > > I'm not having a go at you Joe, or anyone else who has made these points. I > actually agree that this particular issue seems too trivial to warrant a > change, but I'm trying to question if that's the right conclusion (which is > what motivated me to post this thread in the first place). The 'cost' seems > small, and while the 'benefit' seems tiny to us, it might actually be quite > huge for new developers. > > > On Tue, 25 Oct 2016 at 18:20 Joe Groff <[email protected] > <mailto:[email protected]>> wrote: > At this point in Swift's evolution, source-breaking changes to the language > require strong motivation. We can't really entertain superficial keyword > changes like this without overwhelming evidence that the existing syntax is > problematic in practice. `guard` has precedent in functional languages, for > instance in Haskell where the `guard` function is idiomatically used as part > of monadic `do`-notation computations, and has the same positive condition > semantics in those languages. > > -Joe > > > On Oct 25, 2016, at 9:38 AM, Jay Abbott via swift-evolution > > <[email protected] <mailto:[email protected]>> wrote: > > > > I mentioned this in passing on a different thread. Although it caused some > > slight confusion when I first learned the 'guard' keyword, it was easy to > > overcome and I didn't think the issue was strong enough to warrant a > > change. However, after reading the other discussion on that thread (around > > the possibility of a 'matches' keyword and how code is "read out" or > > "internally verbalised"), and seeing how passionate everyone here is about > > Swift, I'm thinking that maybe it should be changed. > > > > The issue is that in English, 'guard' has an inverted logical connotation > > to how it is used in Swift. For example, take this sentence: > > > > "In some functions it's a good idea is to put some checks in place, in > > order to guard against invalid input values." > > > > Swift's 'guard' keyword is to guard against invalid values. > > Or to put it another way, to ensure that we have valid values. > > > > However, the way it reads in Swift, we guard that we have valid values. > > > > I fully understand and agree that it's better to state the true condition > > for valid values here, using else to perform a contingency. And I > > understand why the word 'guard' was picked (given the above example > > sentence). I just think that 'ensure' would be better. > > > > ensure x > 0 else { > > return > > } > > > > ensure camp.isSafe else { > > runForTheHills() > > } > > > > ensure let thingy = object as? Thingy else { > > return ExamineThingyResult.NotAThingy > > } > > > > As I said, I thought it was too small a niggle to worry about, but seeing > > how people on here care so much about making Swift better, and the > > willingness to change things, I thought I'd suggest it. Although it would > > be a breaking change, the code changes are easy. > > > > So what do people think? In particular it would be interesting to hear from > > non-native English speakers on this, did 'guard' confuse you or did 'guard' > > cause your understanding of the English word to be confused? > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
