On 21/05/18 01:36, Maciej Izak wrote:
IMO potentially breaking compatibility is better than lock/prohibition for missing features in Delphi (or waiting for Delphi implementation).
Breaking backwards compatibility is one of the the worst things you can do in a programming language/compiler, and the primary concern when making changes to a language should always be to avoid this (except when you're developing a new language that's still in its infancy).
Even if you design everything with that mindset, you know that you will still have to do it occasionally because you missed certain things or could not foresee them. Especially since no one cares to formally specify and analyse standards for Pascal anymore, so nothing gets vetted properly. Those cases are enough, there is no need to intentionally add more (even if only potential ones).
Breaking backwards compatibility wastes time (both of the developer that has document the change and the users that have to adapt their —or worse, other people's— code), wastes energy on friction (users annoyed that their code no longer works, compiler developers annoyed that users didn't read the changelog, noise on fora/mailing lists, extra bug reports), and breaks the most fundamental expectation of using a high level language (unambiguous/formally correct code that used to compile/work should keep compiling/working; that's the whole point of using a high level language).
Some of the above things can also happen if a particular feature is not available in a certain language mode, but that is bound to the nature of language modes: not all language modes provide the same features and/or features in the same way.
Jonas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
