5 ms·

It will be time for Swift when they stop making backwards-incompatible changes to the syntax and I can be sure my code from today will still compile tomorrow wh

It will be time for Swift when they stop making backwards-incompatible changes to the syntax and I can be sure my code from today will still compile tomorrow when I download the latest version of Xcode.

st3fan 11y ago
Just deal with it.
sssilver 11y ago
The alternative is to either stifle improvements, or to bloat the language. And we all know what that looks like looks at C++ I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. I'm happy to maintain my software in return of working with an elegant, cutting-edge, small, logical language.
- dikaiosune 11y ago
  You don't need breaking changes to get many benefits of a language like swift - for example rust has had very little breakage since hitting 1.0.
  - wallacoloo 11y ago
    Thanks for bringing rust into the discussion - they handle language standardization/evolution very effectively, in my opinion. "Experimental" features are added to the language, but they are all effectively #define-gated for at least one release before being concretized (it's done more pragmatically than a literal #define of course, given that rust doesn't have any concept of #defines). This makes sense in my opinion because it gives an opportunity to evaluate proposed language changes under real-world use-cases before making it official, and people must explicitly opt into the possibility of their code not working with future releases, thus fully knowing and accepting the risks.
- edgyswingset 11y ago
  >I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. At the very early stages of the language, sure. But ten years down the line with significant assets in Swift? I think your opinion will change.
- yxhuvud 11y ago
  There are more alternatives to handle this. For example, the language could provide a tool that does any rewriting for you.
  - manmal 11y ago
    XCode has migrations for stuff they break. They are not perfect, but most of the time, they work.

st3fan 11y ago

Just deal with it.

sssilver 11y ago

The alternative is to either stifle improvements, or to bloat the language. And we all know what that looks like looks at C++ I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. I'm happy to maintain my software in return of working with an elegant, cutting-edge, small, logical language.

dikaiosune 11y ago
You don't need breaking changes to get many benefits of a language like swift - for example rust has had very little breakage since hitting 1.0.
- wallacoloo 11y ago
  Thanks for bringing rust into the discussion - they handle language standardization/evolution very effectively, in my opinion. "Experimental" features are added to the language, but they are all effectively #define-gated for at least one release before being concretized (it's done more pragmatically than a literal #define of course, given that rust doesn't have any concept of #defines). This makes sense in my opinion because it gives an opportunity to evaluate proposed language changes under real-world use-cases before making it official, and people must explicitly opt into the possibility of their code not working with future releases, thus fully knowing and accepting the risks.
edgyswingset 11y ago
>I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. At the very early stages of the language, sure. But ten years down the line with significant assets in Swift? I think your opinion will change.
yxhuvud 11y ago
There are more alternatives to handle this. For example, the language could provide a tool that does any rewriting for you.
- manmal 11y ago
  XCode has migrations for stuff they break. They are not perfect, but most of the time, they work.