> On Oct 25, 2016, at 11:44 AM, Jay Abbott <j...@abbott.me.uk> 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.
These conditions are by their nature subjective and involve gray areas. I'm not denying that. It's true that new developers are an important audience for Swift, but we have a large and growing user base of existing developers now, and we don't want to inflict churn on them without a good justification. By all means, if you or someone else gathered evidence that changing a keyword made a massive improvement in learnability, reduced error rate, or other benefits, we'd pay attention. Our default position has to be to maintain stability absent that. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
