First, backward compatibility isn't free. The reason why you can still compile your "version 1.0" source is because someone gives some thoughts about it and puts some extra efforts to make it happen. Backward compatibility requires maintenance and adds constraints to future development. The more versions you have to support, the more constrained you are. I suggest Go should have a reasonable but limited backward compatibility.
Second, to me, deprecation is more about code repair. Oracle clearly states that the purpose of deprecation is to give developers time to move to the new API, and that the deprecated items may be removed from future versions. To date, Java hasn't removed any, but Oracle has listed several Java APIs to be removed from Java 11. Third, deprecation happens not because someone has better ways of doing things. If someone has better ways of doing things, the new and the old APIs can just coexist without needing any deprecation at all. Deprecation happens because it is no longer feasible to uphold the existing promises using the old API definitions. They may discover new cases where the old APIs will produce incorrect result and that it is not possible to repair the code without changing the API definitions. Hence, you need people to move to the new APIs, because -if they stick to the old APIs- their software will be buggy. Thus, it is not always a good idea to allow "version 1.0" source to compile. Whatever decisions Go Team is going to come up with regarding this, I think being able to deprecate items and have the compiler flashes some warnings whenever these items are used, is a good first step. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
