Dozens Of Rust Updates Merged Ahead Of GCC 13.1

[lowflyer]

better out of box experience leads to easier learning.

You did not mention the core guidelines which are IMHO equally important because of the more educational approach.
"Built in" vs. "make your own" is a philosophical question. The tool-by-tool approach of C++ has demonstrated its flexibility and led to a plethora of publicly available tools. Its development environment can be adapted to every preference and every possible use case. With the "everything already there" philosophy of rust, a developer *has to* deal with an already settled situation. While your claim that this "is easier" is debatable, it may limit growth potential of an aspiring junior programmer.

[lowflyer]

The C++ parser is mind-blowingly complex, parsing Rust is mostly straightforward.

I think you over-exaggerate the C++ complexity. The grammar is complete and public. The non-context-free issue is manageable.

On the rust side, I still have to find a single-page grammar that is complete. If it is so easy, it should not be a problem publishing it.

Rust was not created to be easy to write compilers for.

This is moving the complexity away from the users into the compiler. Therein lies a very philosophical problem: the "trust the experts" approach. It splits the rust community into two classes: one that uses the language and another that creates the language. An "ivory tower of experts" that claim to know what is good for the casual programmer. Isn't this the very thing that is always lamented over C++?

The burden of complexity is at least shared in C++. This causes both, the creators and the users, learn from each other automatically.

[oleid]

You did not mention the core guidelines which are IMHO equally important because of the more educational approach.

Well, that's documentation. We were talking about tooling. Clang-tidy has checks based on core guidelines.

"Built in" vs. "make your own" is a philosophical question.

It has practical consequences. For each new project, you have higher set-up time if things are not built-in.
Also, in case of tools like asan and valgrind, these tools cannot be used at the same time. I.e. you have to disable asan (and recompile everything) to be able to use valgrind.
That time-consuming depending on the size of the codebase. At work it takes up to half an hour.

The tool-by-tool approach of C++ has demonstrated its flexibility and led to a plethora of publicly available tools. Its development environment can be adapted to every preference and every possible use case.

So you're arguing it is better to provide little out of the box and shitty compiler error messages, so that people have to build external tools to cope with the situation.
And don't get me started on the build system situation in the c++ world.

With the "everything already there" philosophy of rust, a developer *has to* deal with an already settled situation. While your claim that this "is easier" is debatable, it may limit growth potential of an aspiring junior programmer.

You're really arguing that people have to go trough a lot of tooling-induced pain in order to get to their full potential?

Anyway, you might be surprised that there are also non-built-in tools in the rust ecosystem available. What is *integrated* into the default compiler is are mostly sane error messages as well as static tooling like what they call "the borrow checker", for which there is no equivalent in the c++ world at the moment. So as you can see, there is not really a settled situation, new tooling is developed in the rust ecosystem. But most of it is either available via rustup or easily install-able via cargo or you can build it along with your project. But even if it was a settled situation, your logic doesn't make sense to me.

[jacob]

I think you over-exaggerate the C++ complexity. The grammar is complete and public. The non-context-free issue is manageable.

On the rust side, I still have to find a single-page grammar that is complete. If it is so easy, it should not be a problem publishing it.

C++11 had to introduce an alternative function declaration syntax because with the old one, the language became unparseable.

This is moving the complexity away from the users into the compiler. Therein lies a very philosophical problem: the "trust the experts" approach. It splits the rust community into two classes: one that uses the language and another that creates the language. An "ivory tower of experts" that claim to know what is good for the casual programmer. Isn't this the very thing that is always lamented over C++?

The very reason why programming languages exist in the first place is to absorb complexity and abstract it away from the user. Nowadays even assembly hides what really goes on inside the CPU. A distinction between language users and language developers is inherent to every language, it's not specific to Rust, and it's how it should be. Linux developers, for example, are interested in developing a kernel, not a compiler or designing a programming language. There is nothing elitist about it, Rust development (as in the development OF Rust, not IN Rust) is open to anyone who wants to participate, but people who want to develop OSes, games, web apps, CAD software or whatever need to be able to focus on their problem, not have to deal with the language itself in the process. D is like that, and it's generally considered to be the primary reason why the language failed.

What is always lamented over C++ is not that it's designed by a dedicated group and not by every single Joe who tries to write Hello World in it. That's the same for C, Rust, Python etc. What is lamented over is that it's an incoherent mess without any unifying vision, it has no robust theoretical foundation, it accumulates myriads of features that mutually break each other and is notoriously so error prone that many of its largest and most experienced users, Microsoft among them, have made it a policy to move away from it.

The burden of complexity is at least shared in C++. This causes both, the creators and the users, learn from each other automatically.

I don't know what do you mean by this.

[lowflyer]

C++11 had to introduce an alternative function declaration syntax because with the old one, the language became unparseable.

What you're trying to say with this? The old function declaration syntax is still there. In C++23. I guess that means it is still parsed.

... is that it's an incoherent mess without any unifying vision, it has no robust theoretical foundation, it accumulates myriads of features that mutually break each other and is notoriously so error prone ...

There you go. - Feel better now`?

I don't know what do you mean by this.

I can't help you if you don't even try.

[lowflyer]

You're really arguing that ...

I'm not arguing. I understand you are sold out to rust and its philosophy. I understand that you're not willing to hear that C++ can be had easier. Try to use rustup or cargo without the internet. There is pain also on the rust side. Error messages that talk rust lingo for example.

And then, there is the all-mighty borrow checker which does "everything that you cannot do with C++". How many times do you have to bring your offerings? hourly? Or is daily sufficient? I have heard that the borrow checker is still not complete yet.

[oleid]

I understand you are sold out to rust and its philosophy.

Well, if you say so. Why do you think that?

I understand that you're not willing to hear that C++ can be had easier.

Sure I'm willing to hear concrete examples. But you didn't provide any.

Try to use rustup or cargo without the internet.

Well, rustup works without internet as long as you don't download anything. Do you see any concrete problems?
Apart from that, why not using rust from your distribution? No need to use rustup.

What't the problem with cargo without internet? It has an offline mode:

https://www.ncameron.org/blog/cargo-offline/

There is pain also on the rust side. Error messages that talk rust lingo for example.

I never claimed that there can be any improvements, as I said. But this doesn't fix the c++ error messages I see day to day.

And then, there is the all-mighty borrow checker which does "everything that you cannot do with C++". How many times do you have to bring your offerings? hourly? Or is daily sufficient?
.

Maybe until lowflyer understood?

I have heard that the borrow checker is still not complete yet.

What software is complete?
There is still research going on. But it will only result in more code being allowed. That doesn't mean it doesn't work today as-is.

[lowflyer]

Well, if you say so. Why do you think that?

see below.

Well, rustup works without internet as long as you don't download anything. Do you see any concrete problems?
Apart from that, why not using rust from your distribution? No need to use rustup.

What't the problem with cargo without internet? It has an offline mode:

• "first you tell me to use rustup which didn't work, then you tell me not to use rustup. Rust is so bloody difficult to set up."
• "rust is not on my windows distribution, and rust is not in the <xx> distribution, so I conclude that rust is a shitty language"
• "Why do I always have to specify that --offline option when the network is out? That's so damn over complicated".

This is just a taste of your own medicine. It is *exactly in the same spirit* how you treat C++. When it comes to rust then "oh that's easy - not a problem at all - much better than anything else - or: well it's unfinished yet". But beware the same thing comes from C++, then it's from the devil in person.

I never claimed that there can be any improvements, as I said. But this doesn't fix the c++ error messages I see day to day.

Yeah, yea, ya... You never claim anything on rust. But when it comes to C++ you'll always remember an error message that was fixed 15 revisions ago.

What software is complete?
There is still research going on. But it will only result in more code being allowed. That doesn't mean it doesn't work today as-is.

You gracefully gloss over it for rust. But you're not willing to extend the same grace to C++.

Maybe until lowflyer understood?

Understood what exactly? I will never join your religion. rust is just another compiler like so many others.

Sure I'm willing to hear concrete examples. But you didn't provide any.

Sincerely, I doubt that. You said we are talking tooling - not concrete examples. Why don't you consider bringing up an example yourself? - And let me chew on it.

An honest discussion about the pros and cons of both languages would be much more interesting. Unfortunately, there are rarely any people in this forum willing to conduct an honest discussion. I know that rust brings a number of good things to the table. But tearing down C++ all the time tells me two things: Your arguments are not worth the screen real-estate they're written on and perhaps rust is not as good as you claim after all.

[oleid]

Why don't you consider bringing up an example yourself? -

Sure. Let's talk about dangling references, e.g. by using the string_view container. How do you make sure that there are none in your code in an automated way. E.g. when using CMake build system and a gitlab CI.


In rust all you have to do is build the project and you are fine if it does.

[oleid]

"first you tell me to use rustup which didn't work, then you tell me not to use rustup. Rust is so bloody difficult to set up."

Rustup will certainly download from the internet, if you don't have the software already installed.
But this is true for most package management software. I told you you can use rust-up to install stuff.
But by no means I told you you have to use it. You can also use your local package manager.

rust is not on my windows distribution, and rust is not in the <xx> distribution, so I conclude that rust is a shitty language

Neither is C++ on your windows distribution. By the way, this isn't a windows forum, so who cares.
Rust is, however, included in all major linux distributions. Probably also in the minor ones, I did not check.

Why do I always have to specify that --offline option when the network is out? That's so damn over complicated.

You don't have to. It makes it just explicit.

This is just a taste of your own medicine. It is *exactly in the same spirit* how you treat C++.

Not really. Okay, please tell me how I mistreated C++?

When it comes to rust then "oh that's easy - not a problem at all - much better than anything else - or: well it's unfinished yet".

Do you have any friends?

I'm sorry, *NO* software is finished. EVEN C++ is not finished. So where is your goddamn problem?

Also, you're putting words into my mouth. Please re-read all the thread. The only thing I claimed is that rust has better out-of-the-box tooling and better integrated static tooling. And thus, it is easier to get going.

But beware the same thing comes from C++, then it's from the devil in person.

Well, if you say so.

Yeah, yea, ya... You never claim anything on rust. But when it comes to C++ you'll always remember an error message that was fixed 15 revisions ago.

15 revisions?

You must know, I do lots of code review at work. Today, somebody had a mile long error message and asked me for help.
It boiled down to the following trivial example. So still get lots of output, even with latest clang. And if this happens in other template-ized context, the output is even longer.

https://godbolt.org/z/7MvE7b3q4

int main()
{
   int a;
   std::vector<std::vector<int>> v;
   auto it = std::find(v.begin(), v.end(), a);
}
​

In file included from <source>:1:
In file included from /opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/vector:60:
In file included from /opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_algobase.h:71:
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/predefined_ops.h:270:17: error: invalid operands to binary expression ('std::vector<int>' and 'const int')
{ return *__it == _M_value; }
~~~~~ ^ ~~~~~~~~
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_algobase.h:2067:8: note: in instantiation of function template specialization '__gnu_cxx::__ops::_Iter_equals_val<const int>:perator()<__gnu_cxx::__normal_iterator<std::vector <int> *, std::vector<std::vector<int>>>>' requested here
if (__pred(__first))
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_algobase.h:2112:14: note: in instantiation of function template specialization 'std::__find_if<__gnu_cxx::__normal_iterator<std:: vector<int> *, std::vector<std::vector<int>>>, __gnu_cxx::__ops::_Iter_equals_val<const int>>' requested here
return __find_if(__first, __last, __pred,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_algo.h:3851:19: note: in instantiation of function template specialization 'std::__find_if<__gnu_cxx::__normal_iterator<std:: vector<int> *, std::vector<std::vector<int>>>, __gnu_cxx::__ops::_Iter_equals_val<const int>>' requested here
return std::__find_if(__first, __last,
^
<source>:8:20: note: in instantiation of function template specialization 'std::find<__gnu_cxx::__normal_iterator<std::vecto r<int> *, std::vector<std::vector<int>>>, int>' requested here
auto it = std::find(v.begin(), v.end(), a);
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/allocator.h:205:7: note: candidate function not viable: no known conversion from 'std::vector<int>' to 'const allocator<int>' for 1st argument
operator==(const allocator&, const allocator&) _GLIBCXX_NOTHROW
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_pair.h:640:5: note: candidate template ignored: could not match 'pair' against 'vector'
operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:444:5: note: candidate template ignored: could not match 'reverse_iterator' against 'vector'
operator==(const reverse_iterator<_Iterator>& __x,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:489:5: note: candidate template ignored: could not match 'reverse_iterator' against 'vector'
operator==(const reverse_iterator<_IteratorL>& __x,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:1213:5: note: candidate template ignored: could not match '__normal_iterator' against 'vector'
operator==(const __normal_iterator<_IteratorL, _Container>& __lhs,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:1221:5: note: candidate template ignored: could not match '__normal_iterator' against 'vector'
operator==(const __normal_iterator<_Iterator, _Container>& __lhs,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:1656:5: note: candidate template ignored: could not match 'move_iterator' against 'vector'
operator==(const move_iterator<_IteratorL>& __x,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:1726:5: note: candidate template ignored: could not match 'move_iterator' against 'vector'
operator==(const move_iterator<_Iterator>& __x,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/new_allocator.h:196:2: note: candidate template ignored: could not match 'const __new_allocator<_Up>' against 'const int'
operator==(const __new_allocator&, const __new_allocator<_Up>&)
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/allocator.h:219:5: note: candidate template ignored: could not match 'allocator' against 'vector'
operator==(const allocator<_T1>&, const allocator<_T2>&)
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_vector.h:2035:5: note: candidate template ignored: could not match 'const vector<_Tp, _Alloc>' against 'const int'
operator==(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y)
^
1 error generated.
ASM generation compiler returned: 1
In file included from <source>:1:
In file included from /opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/vector:60:
In file included from /opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_algobase.h:71:
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/predefined_ops.h:270:17: error: invalid operands to binary expression ('std::vector<int>' and 'const int')
{ return *__it == _M_value; }
~~~~~ ^ ~~~~~~~~
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_algobase.h:2067:8: note: in instantiation of function template specialization '__gnu_cxx::__ops::_Iter_equals_val<const int>:perator()<__gnu_cxx::__normal_iterator<std::vector <int> *, std::vector<std::vector<int>>>>' requested here
if (__pred(__first))
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_algobase.h:2112:14: note: in instantiation of function template specialization 'std::__find_if<__gnu_cxx::__normal_iterator<std:: vector<int> *, std::vector<std::vector<int>>>, __gnu_cxx::__ops::_Iter_equals_val<const int>>' requested here
return __find_if(__first, __last, __pred,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_algo.h:3851:19: note: in instantiation of function template specialization 'std::__find_if<__gnu_cxx::__normal_iterator<std:: vector<int> *, std::vector<std::vector<int>>>, __gnu_cxx::__ops::_Iter_equals_val<const int>>' requested here
return std::__find_if(__first, __last,
^
<source>:8:20: note: in instantiation of function template specialization 'std::find<__gnu_cxx::__normal_iterator<std::vecto r<int> *, std::vector<std::vector<int>>>, int>' requested here
auto it = std::find(v.begin(), v.end(), a);
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/allocator.h:205:7: note: candidate function not viable: no known conversion from 'std::vector<int>' to 'const allocator<int>' for 1st argument
operator==(const allocator&, const allocator&) _GLIBCXX_NOTHROW
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_pair.h:640:5: note: candidate template ignored: could not match 'pair' against 'vector'
operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:444:5: note: candidate template ignored: could not match 'reverse_iterator' against 'vector'
operator==(const reverse_iterator<_Iterator>& __x,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:489:5: note: candidate template ignored: could not match 'reverse_iterator' against 'vector'
operator==(const reverse_iterator<_IteratorL>& __x,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:1213:5: note: candidate template ignored: could not match '__normal_iterator' against 'vector'
operator==(const __normal_iterator<_IteratorL, _Container>& __lhs,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:1221:5: note: candidate template ignored: could not match '__normal_iterator' against 'vector'
operator==(const __normal_iterator<_Iterator, _Container>& __lhs,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:1656:5: note: candidate template ignored: could not match 'move_iterator' against 'vector'
operator==(const move_iterator<_IteratorL>& __x,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_iterator.h:1726:5: note: candidate template ignored: could not match 'move_iterator' against 'vector'
operator==(const move_iterator<_Iterator>& __x,
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/new_allocator.h:196:2: note: candidate template ignored: could not match 'const __new_allocator<_Up>' against 'const int'
operator==(const __new_allocator&, const __new_allocator<_Up>&)
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/allocator.h:219:5: note: candidate template ignored: could not match 'allocator' against 'vector'
operator==(const allocator<_T1>&, const allocator<_T2>&)
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_vector.h:2035:5: note: candidate template ignored: could not match 'const vector<_Tp, _Alloc>' against 'const int'
operator==(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y)
^
1 error generated.

Execution build compiler returned: 1

Same snippet in rust:

https://godbolt.org/z/v84xPYK1T

fn main()
{
   let a = 0;
   let v = Vec::<Vec<i32>>::new();

   v.iter().find(|&val| a == *val);
}

error[E0277]: can't compare `{integer}` with `Vec<i32>`
--> <source>:6:28
|
6 | v.iter().find(|&val| a == *val);
| ^^ no implementation for `{integer} == Vec<i32>`
|
= help: the trait `PartialEq<Vec<i32>>` is not implemented for `{integer}`
= help: the following other types implement trait `PartialEq<Rhs>`:
f32
f64
i128
i16
i32
i64
i8
isize
and 6 others

error: aborting due to previous error

Granted, stuff like this *will* get better when we have concepts and c++23, but there isn't even a compiler today that fully supports c++23. Who knows when we can use it at work.
Hopefully we'll do the switch of the main shared codebase to c++20-only, soon.

The other day, another person hand the following problem in their code.
A result of work-arounds we have to use in c++ due to limited support for variants:

https://godbolt.org/z/TPzbKae34

#include <variant>
#include <iostream>

int main()
{
    std::variant<float, int> val;

    std::visit([](auto v) {
        using T = std::decay<decltype(v)>;

        if constexpr(std::is_same_v<T, float>)
        {
            std::cerr << "float " << v;
        }
        else if constexpr(std::is_same_v<T, int>)
        {
            std::cerr << "int " << v;
        }
        else
        {
            std::cerr << "No implementation\n";
        }
    }, val);
}​

Logic error due to a simple typo. No compiler hint, no static analysis help from what we typically use (clang-tidy, cppcheck, ...). Very unhelpful.
Proper support for sum type would have been nice. But certainly, once you know the quirks you take special care and you work around. As always.