2 ms·

This is of course false. The active subset is always the set of features not supplanted by the latest Standard supported by tooling in use. Anything newer is s

by ncmncm 4y ago

This is of course false. The active subset is always the set of features not supplanted by the latest Standard supported by tooling in use. Anything newer is safer and nicer than old crap, so there is no temptation to stick to old crap, except among people who have elected not to learn anything new. Those are typically approaching retirement anyway.

tialaramex 4y ago
What part is false? The part where Vittorio proposed Epochs to fix this? The part where the Committee decided not to take it? Do you think that fixing this will magically get easier if you wait longer?
- pjmlp 4y ago
  The part that the community misses the point epochs only work with FOSS source code and having the same compiler compiling everything from scratch.
  - tialaramex 4y ago
    There's nothing about Epochs which cares about software licensing. Yes, you will need the source code to C++ software to actually compile it but the relationship to licensing is at most coincidental. Much of the time when you really can't negotiate source code, it's because it's a "pig in a poke" IP sale, what you're buying was actually either worthless or the seller never really owned it anyway. The video games industry is certainly rife with this.
    - pjmlp 4y ago
      Doesn't matter, a solution burned in ISO papers needs to work for everyone, not only for free source code advocates.
      - tialaramex 4y ago
        "Because of ISO" has to be the lamest C++ excuse, and perhaps the fact it's seeing more use recently reflects a larger problem. Also, remember, that ISO document is known for two decades to not actually describe the language as implemented, but the fix (pointer provenance) is controversial enough that the committee keeps "forgetting" to fix it. The ISO document describes an imaginary language which would be incredibly slow and useless if it really existed, the document exists because the real C++ language is sort-of similar to this imaginary language and for some people (though it seems gradually fewer over time) that's enough. Any pretence that ISO requires it to "work for everyone" is nonsense since as documented it isn't in fact working for anyone. † One of the fun side effects is that you can't explain what ARM Morello ports do in terms of the ISO standard. CHERI reifies provenance, which would be fine if the standards document explained what provenance is, but the C and C++ documents deliberately do not do that. On paper Morello ports just waste space to make some valid programs crash, which is weird.
        pjmlp 4y ago
        Yes, it reflects the problem that Rust advocates miss the point of some industries work outside FOSS. Ironically you point out CHERI, so when is the Rust memory model going to be fixed to fully support it, and catch up with C and C++ on that front? Is Aria done with her blog posts? The ISO clay tablets do happen to work for more people than Rust in its current state, even if they are a bit fragile. But it is ok, assuming that Rust's main goals isn't to cover all industry use cases supported by C and C++ in 2022.
        tialaramex 4y ago
        You can do CHERI with Rust exactly as it stands (and people have done that), it's just that usize and isize are bigger than you'd want because now we're stashing provenance, so the other options are worth exploring. Rust actually talks about provenance (messing with pointers is of course unsafe so it doesn't need to worry about this in most of The Book) so this isn't a mystery in Rust. Indeed the API as it stood before Aria's work already makes it clear that you're stepping off the edge of the cliff if you try to do address arithmetic and similar provenance defeating magic. Aria's "Tower of weakenings" is about firming up some of those first steps, allowing us to do some Road Runner don't-look-down bullshit and know whether we can get away with it on real hardware with the real compiler, while still forbidding things that are definitely crazy (the ISO documents say such things work in C++, but they do not work in actual C++ compilers, they have, drum roll... Undefined Behaviour). Aria did a bit more than write some blog posts, for example: https://doc.rust-lang.org/core/primitive.pointer.html#method.with_addr https://doc.rust-lang.org/core/primitive.pointer.html#method... Again though, this isn't about licenses. Regardless of why you don't have source code, that's where the problem is. "Gee, it's difficult to compile this program without source code" is maybe something where C wants to draw a line in the sand because of its very simple ABI but C++ is a long way past the point where that's useful and people need to stop pretending otherwise, it's a cause of enormous frustration in the community.
  - SuperV1234 4y ago
    > epochs only work with FOSS source code Huh?
    - pjmlp 4y ago
      The way Rust epochs work requires a compiler that is fully aware of all existing epochs, and goes through all the code applying the epoch semantics the crate expect on their build definition. Also epochs can't introduce backwards incompatible semantics that break across epochs, imagine a crate exporting something whose representation at runtime changes between epochs and is used as parameter in some callback implementated in that epoch.
      - tialaramex 4y ago
        Syntax. Rust (since 1.0 in 2015) has a single Abstract Syntax, and the written syntax of each Edition is translated to the Abstract Syntax. Rust provides tools which will do the equivalent transformation to your actual code, but of course this transliteration is ugly, so the preferred form for further development of a 2015 edition crate is the 2015 edition code, the transform is useful if you've decided to actually update to a newer edition so that it serves as a working (but perhaps slightly ugly) start. This is already rather more compatibility than C++ has delivered. Rust 2015 Edition works just fine on a brand new Rust compiler in 2022, whereas a C++ 20 compiler can't always compile valid C++ 98, C++ 08, C++ 11, C++ 14 or C++ 17 code except via a "version" switch of some sort. They are, ultimately six distinct versions of the language. It's true that this limits what is possible with a Rust Edition. However, because so much is possible it inspires people putting in that extra little bit of effort to get it done compatibly. Example, Rust 1.0 you couldn't just iterate over an array. The built-in arrays don't implement IntoIterator because that needs const generics and Rust 1.0 didn't have const generics. Fast forward to Rust 2021 edition, and this works. But wait, that's syntactically impossible. You can't have arrays only implement IntoIterator on newer editions, that's not syntax. So there's a hack. On modern compilers for Rust 2015 and 2018 editions, when you write x.into_iter() if "x" is an array, it silently ignores the fact it knows arrays are IntoIterator and continues considering other options, crucially (&x).into_iter() the iterator over a reference. That's all the hack does though, so arrays are IntoIterator, you can use them as you'd expect for a container even from Rust 2015 code now, you can for loop over them, you can pass them to functions which want IntoIterator, you just can't use this method call syntax which would always have done something else. This feature costs Rust a little hack in the 2015 and 2018 edition parsers forever and that's all.
mianos 4y ago
There is still a very large set of people using older style C++. particularly those that came from C. I can assure you they are a long long way from retirement. This is particularly true of large code-bases in established firms. Personally, I think it would be an interesting idea to soft ban a lot of pointer use and only allow shared and unique. As pointed out in an earlier comment, it is a 'python' like experience without the performance compromise. This said, the exception is when you need to use well tested existing libraries such as libmicrohttp to implement a local REST server without buying into some mega framework.

by ncmncm 4y ago

tialaramex 4y ago

What part is false? The part where Vittorio proposed Epochs to fix this? The part where the Committee decided not to take it? Do you think that fixing this will magically get easier if you wait longer?

pjmlp 4y ago
The part that the community misses the point epochs only work with FOSS source code and having the same compiler compiling everything from scratch.
- tialaramex 4y ago
  There's nothing about Epochs which cares about software licensing. Yes, you will need the source code to C++ software to actually compile it but the relationship to licensing is at most coincidental. Much of the time when you really can't negotiate source code, it's because it's a "pig in a poke" IP sale, what you're buying was actually either worthless or the seller never really owned it anyway. The video games industry is certainly rife with this.
  - pjmlp 4y ago
    Doesn't matter, a solution burned in ISO papers needs to work for everyone, not only for free source code advocates.
    - tialaramex 4y ago
      "Because of ISO" has to be the lamest C++ excuse, and perhaps the fact it's seeing more use recently reflects a larger problem. Also, remember, that ISO document is known for two decades to not actually describe the language as implemented, but the fix (pointer provenance) is controversial enough that the committee keeps "forgetting" to fix it. The ISO document describes an imaginary language which would be incredibly slow and useless if it really existed, the document exists because the real C++ language is sort-of similar to this imaginary language and for some people (though it seems gradually fewer over time) that's enough. Any pretence that ISO requires it to "work for everyone" is nonsense since as documented it isn't in fact working for anyone. † One of the fun side effects is that you can't explain what ARM Morello ports do in terms of the ISO standard. CHERI reifies provenance, which would be fine if the standards document explained what provenance is, but the C and C++ documents deliberately do not do that. On paper Morello ports just waste space to make some valid programs crash, which is weird.
      - pjmlp 4y ago
        Yes, it reflects the problem that Rust advocates miss the point of some industries work outside FOSS. Ironically you point out CHERI, so when is the Rust memory model going to be fixed to fully support it, and catch up with C and C++ on that front? Is Aria done with her blog posts? The ISO clay tablets do happen to work for more people than Rust in its current state, even if they are a bit fragile. But it is ok, assuming that Rust's main goals isn't to cover all industry use cases supported by C and C++ in 2022.
        tialaramex 4y ago
        You can do CHERI with Rust exactly as it stands (and people have done that), it's just that usize and isize are bigger than you'd want because now we're stashing provenance, so the other options are worth exploring. Rust actually talks about provenance (messing with pointers is of course unsafe so it doesn't need to worry about this in most of The Book) so this isn't a mystery in Rust. Indeed the API as it stood before Aria's work already makes it clear that you're stepping off the edge of the cliff if you try to do address arithmetic and similar provenance defeating magic. Aria's "Tower of weakenings" is about firming up some of those first steps, allowing us to do some Road Runner don't-look-down bullshit and know whether we can get away with it on real hardware with the real compiler, while still forbidding things that are definitely crazy (the ISO documents say such things work in C++, but they do not work in actual C++ compilers, they have, drum roll... Undefined Behaviour). Aria did a bit more than write some blog posts, for example: https://doc.rust-lang.org/core/primitive.pointer.html#method.with_addr https://doc.rust-lang.org/core/primitive.pointer.html#method... Again though, this isn't about licenses. Regardless of why you don't have source code, that's where the problem is. "Gee, it's difficult to compile this program without source code" is maybe something where C wants to draw a line in the sand because of its very simple ABI but C++ is a long way past the point where that's useful and people need to stop pretending otherwise, it's a cause of enormous frustration in the community.
- SuperV1234 4y ago
  > epochs only work with FOSS source code Huh?
  - pjmlp 4y ago
    The way Rust epochs work requires a compiler that is fully aware of all existing epochs, and goes through all the code applying the epoch semantics the crate expect on their build definition. Also epochs can't introduce backwards incompatible semantics that break across epochs, imagine a crate exporting something whose representation at runtime changes between epochs and is used as parameter in some callback implementated in that epoch.
    - tialaramex 4y ago
      Syntax. Rust (since 1.0 in 2015) has a single Abstract Syntax, and the written syntax of each Edition is translated to the Abstract Syntax. Rust provides tools which will do the equivalent transformation to your actual code, but of course this transliteration is ugly, so the preferred form for further development of a 2015 edition crate is the 2015 edition code, the transform is useful if you've decided to actually update to a newer edition so that it serves as a working (but perhaps slightly ugly) start. This is already rather more compatibility than C++ has delivered. Rust 2015 Edition works just fine on a brand new Rust compiler in 2022, whereas a C++ 20 compiler can't always compile valid C++ 98, C++ 08, C++ 11, C++ 14 or C++ 17 code except via a "version" switch of some sort. They are, ultimately six distinct versions of the language. It's true that this limits what is possible with a Rust Edition. However, because so much is possible it inspires people putting in that extra little bit of effort to get it done compatibly. Example, Rust 1.0 you couldn't just iterate over an array. The built-in arrays don't implement IntoIterator because that needs const generics and Rust 1.0 didn't have const generics. Fast forward to Rust 2021 edition, and this works. But wait, that's syntactically impossible. You can't have arrays only implement IntoIterator on newer editions, that's not syntax. So there's a hack. On modern compilers for Rust 2015 and 2018 editions, when you write x.into_iter() if "x" is an array, it silently ignores the fact it knows arrays are IntoIterator and continues considering other options, crucially (&x).into_iter() the iterator over a reference. That's all the hack does though, so arrays are IntoIterator, you can use them as you'd expect for a container even from Rust 2015 code now, you can for loop over them, you can pass them to functions which want IntoIterator, you just can't use this method call syntax which would always have done something else. This feature costs Rust a little hack in the 2015 and 2018 edition parsers forever and that's all.

mianos 4y ago

There is still a very large set of people using older style C++. particularly those that came from C. I can assure you they are a long long way from retirement. This is particularly true of large code-bases in established firms. Personally, I think it would be an interesting idea to soft ban a lot of pointer use and only allow shared and unique. As pointed out in an earlier comment, it is a 'python' like experience without the performance compromise. This said, the exception is when you need to use well tested existing libraries such as libmicrohttp to implement a local REST server without buying into some mega framework.