Post
@obrhoff Yup, same. Folks (especially smaller teams) have no real need to adopt all the complexity that comes with Swift 6 for the tiny reward at the end. It's also very difficult to sell as a "feature" or something we should spend time on. Swift 6 is not something the community needed or asked for at this point.. it's like a stick without a carrot.
And did I mention it's absurdly complex? Even blogs and tutorials on the topic can't eli5
@obrhoff Yup, same. Folks (especially smaller teams) have no real need to adopt all the complexity that comes with Swift 6 for the tiny reward at the end. It's also very difficult to sell as a "feature" or something we should spend time on. Swift 6 is not something the community needed or asked for at this point.. it's like a stick without a carrot.
And did I mention it's absurdly complex? Even blogs and tutorials on the topic can't eli5
@iamkonstantin @obrhoff Same here. We鈥檙e a studio so we get hired by some large corporations who have existing code and just want to do their next set of features. Time to refactor or adopt new technologies just isn鈥檛 on their mind. If you can do it as part of a new feature that鈥檚 how it gets done.
Transitioning a bunch of code to Swift 6 that already works well and is stable seems like lunacy.
@fahrni @iamkonstantin Agree, but how to break out of this loop since producing more legacy code makes it in the future more unlikely?
A space for Bonfire maintainers and contributors to communicate
