4 ms·

The real solution, which decades from now will be the eventual common-place, but no one dares to imaging the possibility today is that when languages deprecate

The real solution, which decades from now will be the eventual common-place, but no one dares to imaging the possibility today is that when languages deprecate a feature, the compilers deliver code-mods that migrate your code-base perfectly. But people are afraid of going that route because of the bad press around Python 2 / 3. We need a new generation of developers that don't remember that. Today, there's already static-code analysis tools that automatically migrate entire code-bases to use new language constructs. The technology is there. It's the people who lack imagination to make it happen. Once it becomes commonplace, a large % of developers will care very little if some obscure feature of C is dropped. They'll just enjoy having a more streamlined language with all the legacy crap gone.

tialaramex 4y ago
Transformations are difficult. Rust provides best effort transformation for its Editions (which only touch syntax) in cargo fix --edition, but even that's only best effort. If a proc macro does something ludicrous (see Mara's whichever-compiles! macro for example) how can the transformation hope to keep up? C++ versions are in much deeper, they not only change the language syntax, but also semantics of existing features. Sometimes the intended effect is null (but intentions may not match reality) and sometimes it is not. C++ also substantially changes the standard library. Rust's standard library grows but doesn't get redefined in new Editions, so if you call a deprecated Rust function it's not going anywhere, whereas a deprecated C++ method might actually go away in a future version. It's a shame that the best effort tools aren't provided with C++ compilers, but even if they were provided on a large codebase it's only the beginning for large projects.
- account42 4y ago
  clang-tidy is such a tool, provided with a C++ compiler - although incomplete
Calavar 4y ago
UB throws a huge wrench into all of this. The behavior of a C++ program is defined by a combination of the code, the compiler, the compiler flags, and the target archecture. You can't write a source to source translator that preserves the semantics of a program with UB without that extra information about how it was compiled. It's a very hairy problem.
01100011 4y ago
Doesn't Google Abseil, the standard library replacement, do this? https://abseil.io/ https://abseil.io/
- ncmncm 4y ago
  It is not a replacement, it is a staging ground and annex.
sixstringtheory 4y ago
Swift is another one that has had a really bad migration between major versions, I can’t really remember now but it was either 2->3 or 3->4. They had a static migrator and it barely helped, it would get into loops where it would e.g. flip flop between two different uncompileable fixups. Seems like this is a really hard problem, what is an example of a platform that has solved it perfectly or is even close? Swift was a brand new language, it should be easiest to do it there vs any system with legacy (although it was designed to interoperate with ObjC, so… maybe legacy remains).
- pixelrevision 4y ago
  It was 2-3. My take at the time was that they built an add-on to crash xcode.

tialaramex 4y ago

Transformations are difficult. Rust provides best effort transformation for its Editions (which only touch syntax) in cargo fix --edition, but even that's only best effort. If a proc macro does something ludicrous (see Mara's whichever-compiles! macro for example) how can the transformation hope to keep up? C++ versions are in much deeper, they not only change the language syntax, but also semantics of existing features. Sometimes the intended effect is null (but intentions may not match reality) and sometimes it is not. C++ also substantially changes the standard library. Rust's standard library grows but doesn't get redefined in new Editions, so if you call a deprecated Rust function it's not going anywhere, whereas a deprecated C++ method might actually go away in a future version. It's a shame that the best effort tools aren't provided with C++ compilers, but even if they were provided on a large codebase it's only the beginning for large projects.

account42 4y ago
clang-tidy is such a tool, provided with a C++ compiler - although incomplete

Calavar 4y ago

UB throws a huge wrench into all of this. The behavior of a C++ program is defined by a combination of the code, the compiler, the compiler flags, and the target archecture. You can't write a source to source translator that preserves the semantics of a program with UB without that extra information about how it was compiled. It's a very hairy problem.

01100011 4y ago

Doesn't Google Abseil, the standard library replacement, do this? https://abseil.io/ https://abseil.io/

ncmncm 4y ago
It is not a replacement, it is a staging ground and annex.

sixstringtheory 4y ago

Swift is another one that has had a really bad migration between major versions, I can’t really remember now but it was either 2->3 or 3->4. They had a static migrator and it barely helped, it would get into loops where it would e.g. flip flop between two different uncompileable fixups. Seems like this is a really hard problem, what is an example of a platform that has solved it perfectly or is even close? Swift was a brand new language, it should be easiest to do it there vs any system with legacy (although it was designed to interoperate with ObjC, so… maybe legacy remains).

pixelrevision 4y ago
It was 2-3. My take at the time was that they built an add-on to crash xcode.