There are fields where there is no swift culture at all, or barely none, for example on the server side. I don’t want to see « swift-django » winning this battle. I like compile-type safety, because i know that in the long term it makes my code more manageable. But in some cases it’s hard to promote long term over short term. It’s hard to tell someone in your team « yes, you should take the time to define that struct for parsing your JSON api , even if you’ve got tight delay, rather than rely on dynamiclookup ».
Best practices don’t magically conquer a community, they do so because senior devs start banning the dangerous ones and because the language or compiler warning help them to. > Le 8 déc. 2017 à 09:04, Nick Keets via swift-evolution > <swift-evolution@swift.org> a écrit : > > I think this distills the fears of some of the people that are against this > proposal. To paraphrase, it is the fear that the dynamic type barbarians will > come and pillage our villages. > > I on the other hand would welcome this highly hypothetical sub community. I > would also welcome an obfuscated swift sub community, a non-ascii names sub > community and any other weird sub community. I mean, why not? They are not > going to affect my code or the libraries I use. Why not let them exist? > What's with the elitism? > > >> On Fri, Dec 8, 2017 at 4:09 AM, Letanyan Arumugam via swift-evolution >> <swift-evolution@swift.org> wrote: >> Okay I’ll concede and hope that a sub community, who are forced to use Swift >> because of the success of this proposal and others to follow, doesn’t form >> creating their own separate design patterns and beliefs :) > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
