4 ms·
That’s the fun thing about backward compatibility. You can never clean up technically supported things that were never intended. It would be cool if we could h
by imoverclocked 4y ago
That’s the fun thing about backward compatibility. You can never clean up technically supported things that were never intended.
It would be cool if we could have some kind of pragma or alternate syntax (file extension?) that gets rid of these unwanted ambiguities every decade or so. How to do that while avoiding the whole “Perl 6” can of worms might be the hard part though.
- KptMarchewa 4y agoRust editions? They work on per crate, rather than per file level though.
- pron 4y agoIn Java you set the language version per source file, and there are occasional and uncommon source incompatibilities, but it's still not worth it to introduce a common incompatibility (which isn't really the case here, anyway).
- KptMarchewa 4y agoThey still all compile to some set bytecode version, right?
- pron 4y agoThe target bytecode/standard library version can also be specified on a per-file basis (we have both -source and -target options). But while the VM can load a classfile of any version since the beginning of time, the javac compiler supports only a certain number of versions back in terms of source version and target version (e.g. you can't use a JDK 19 compiler to target JDK 7, but you can ask for the same language, API, and bytecode level as 15).
- nativecoinc 4y agoPerl 5 has that. Perl 5 seems to have all these annoying boilerplate lines that you need to add to every file in order to get “Perl The Good Parts”. But I think (I read) that they managed to boil it down to just one line.