You are a stupid programmer, you can't have that

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Aug 10 19:18:47 UTC 2021


On Tue, Aug 10, 2021 at 06:46:57PM +0000, Paul Backus via Digitalmars-d wrote:
> On Tuesday, 10 August 2021 at 17:47:48 UTC, H. S. Teoh wrote:
[...]
> > OT1H the idealist in me screams "please break my code, fix the
> > language to remove all the broken stuff!".  OTOH the long-term code
> > maintainer in me shakes his fists every time a compiler upgrade
> > breaks one of my old projects.
> > 
> > The solution to the conundrum is, accretion rather than replacement.
> > Let the old code compile.  Complain about deprecations if you have
> > to, but don't ever make it not compile (unless it was an outright
> > bug to have compiled in the first place).  But new code can use the
> > new stuff and benefit from it.
> 
> Of course, the obvious counterargument is that this approach is
> exactly how you end up with a language like C++: powerful in the hands
> of experts, with a large and successful ecosystem, but packed to the
> gills with pitfalls and footguns for beginners to hurt themselves
> with.
[...]

Very true.

Which is why one time I brought up this idea of embedding language
version in source files.  Perhaps right after the module declaration
there could be an optional version declaration that states which
language version the source file was written for:

	module mymodule;
	version = 2.097;
	...

If the version declaration is earlier than the current compiler version,
it would enter compatibility mode in which it emulates the behaviour of
a previous language version.  But if the version declaration is
up-to-date or omitted, the compiler would apply the latest version of
the language, which may or may not break older features.  That gives us
a way to fix flaws in the language and reverse design decisions that
were wrong in hindsight, yet without breaking old code.  Newer code
would then be encouraged to use the latest language version, that does
not have the pitfalls of older language versions.

Of course, in practice this will add a whole ton of extra work for the
compiler devs, especially once the number of supported language versions
increases.  And it's not clear what to do if an older language construct
has to interact with a newer, incompatible language feature.  So I'm not
sure how practical this will be.  But if we could somehow pull it off,
then we could *both* evolve the language and retain backward
compatibility at the same time.


T

-- 
Fact is stranger than fiction.


More information about the Digitalmars-d mailing list